The original reason for grabbing the module prefix was to make the cache keys unique, so that two modules that both defined a form bean named "foo" (but perhaps with different properties) would not clash.
The approach you recommend seems reasonable, and accomplishes that same goal ... but if we're going to be a factory, we might as well be a factory for action form instances (as you suggest), so the FormBeanConfig method would be something like:
public ActionForm createActionForm(ActionServlet servlet)
instead. The dynamic create version would use the restored method signature in DynaActionFormClass (which the struts-faces library routine would still need to call in order to remain 1.1-compatible).
Does that sound right? If so, I'm +1 for such a patch, and will do so later tonight if you don't beat me.
Craig
Niall Pemberton wrote:
I just attached a patch to Bug[22207] which changes the method signiture back to its original form.
http://issues.apache.org/bugzilla/show_bug.cgi?id=22207
Niall
----- Original Message ----- From: "Niall Pemberton" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 7:47 PM
Subject: Re: Struts-Faces and Version Dependencies
The only reason for needing the ModuleConfig is to get the module prefixfor
easythe key to store the DynaActionFormClass in the "static" cache in DynaActionFormClass .
My suggestion would to to get rid of the static "cache" of DynaActionFormClasses and store them in their respective FormBeanConfig - that way there would be no need for a reference to the ModuleConfig.
Taking this further, you could then provide a method in the FormBeanConfig
to create a new DynaActionForm or in fact any ActionForm making it very
for someone to generate a new ActionForm in the Action if they required.But
I don't know what you think about turing the FormBeanConfig from justActionForms?
containing the "config" info to making it also a "factory" for
Niall
----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 6:41 PM
Subject: Struts-Faces and Version Dependencies
I'm woefully behind in dealing with Struts issues due to "day job" responsibilities, but I finally took the time to discover why the Struts-Faces nightly builds have been failing. Unfortunately, we've created a public API discrepancy in the latest CVS code (versus 1.1) that affects the library.
In Struts 1.1, the org.apache.struts.action.DynaActionFormClass included the method signature:
public static DynaActionClass createDynaActionFormClass(FormBeanConfig config);
But in version 1.18 of this class (as part of dealing with Bugzilla #22207[1] ), we changed the method signature to:
public static DynaActionClass createDynaActionFormClass(FormBeanConfig config, ModuleConfig moduleConfig);
The change was necessitated by the fact that a FormBeanConfig no longer has a reference to the ModuleConfig for the module containing it, so it had to be passed in. The net result is that the Struts-Faces library can be built against either Struts 1.1 or Struts 1.2, but not both :-(.
I'd be willing to consider a 1.2 dependency if we had a GA quality release available; but I'd also rather not try to release struts-faces for 1.1 only and then have to rev it for Struts 1.2 solely to deal with this issue (in all other respects that I have tested, struts-faces seems to work fine on either).
Any ideas? In particular, is there a way to deal with the serialization issue that was described in the bug report, without having to change this method signature?
In the longer term, I think we do need to be somewhat more careful about public API changes in 1.x versions. One of the reasons Struts is powerful is precisely because there are many extensions built around it ... and making life harder on people building those extensions isn't conducive to that continuing.
Craig
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=22207
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
