The only reason for needing the ModuleConfig is to get the module prefix for the 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 easy 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 just containing the "config" info to making it also a "factory" for ActionForms? 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]
