Thanks for putting the effort into a solution for this Hubert, it will be a good addition to Struts. I have a couple of comments....
I'm wondering whether as well as what you suggest we should also inherit the actual FormBeanConfig as well? This would make it far more complex to implement because of any custom properties that the user might have set using the <set-property> element. Its probably not a big deal for form beans - but when it comes to implementing this kind of inheritance for action mappings and forwards I think its an issue we would need to deal with and my gut feel is that this feature needs to work consistently for all the elements of the struts-config and not one way for action forms and another for action mappings. Secondly, what about modules? Should we allow inheritance from other modules and/or if a form bean doesn't exist in the current module - then check the deault one? Niall ----- Original Message ----- To: "Struts Developers List" <dev@struts.apache.org> Sent: Tuesday, February 22, 2005 3:07 PM > I tried this over the weekend, starting with form beans. > Here's what my sample app had: > > <!-- the form I extend --> > <form-bean name="baseForm" > type="o.a.s.a.DynaActionForm"> > <form-property name="firstName" type="java.lang.String"/> > <form-property name="lastName" type="java.lang.String"/> > <form-property name="score" type="java.lang.String"/> > </form-bean> > > <!-- this is the form my actions used --> > <form-bean name="basicForm" > extends="baseForm"> > <form-property name="score" initial="100"/> > <form-property name="attempts" type="java.lang.String"/> > </form-bean> > > > The idea is that basicForm will end up with: > <form-bean name="basicForm" > type="o.a.s.a.DynaActionForm"> > <form-property name="firstName" type="java.lang.String"/> > <form-property name="lastName" type="java.lang.String"/> > <form-property name="score" type="java.lang.String" initial="100"/> > <form-property name="attempts" type="java.lang.String"/> > </form-bean> > > The following values would be inherited: > FormBeanConfig.type > > ...and for each property: > FormPropertyConfig class > FormPropertyConfig.name > FormPropertyConfig.type > FormPropertyConfig.initial > FormPropertyConfig.size > > ...unless a "subform" overrides it. > So in the example above, if basicForm included an entry > stating the "score" field should use "java.lang.Integer", that's > what the end result would have. It would still inherit "initial" > and "size" if the "superform" specified it. > > For something like this, I had to remove the "type" > requirement for the <form-bean> and <form-property> elements. > > The extension gets realized before the loop which creates and > registers the DynaActionFormClass instances. This code is still > in the ActionServlet.initModuleConfig() method, so I've extracted > this into its own method. Simple checks for circular inheritance > can be easily done by FormBeanConfig, but more complex checking > should probably be done by a separate method in ActionServlet, or > maybe in a util class, such as ModuleUtils. > > Comments, please. > > I can start working on some unit tests next. > I may have some time tomorrow night. > > > On Mon, 14 Feb 2005 17:39:34 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > One thing which has been talked about in a few places, and which > > would be valuable, but which no one has done any work on is > > implementing "extends" in as many places in struts-config.xml as it > > would be useful, to eliminate repeated chunks of XML. For > > Validation, this would really be an enhancement to commons-validator, > > but perhaps the same general strategy could be applied. I haven't > > even looked at what would be involved in trying to implement it. > > Which other places would this make sense to do? > Exception handlers, forwards, and action mappings? > I haven't taken a look at these yet. > For exception handlers and forwards, should action-specific config be > allowed to extend global config? Hmm... I'm thinking yes; I haven't thought > of a reason not to, yet. > > As for Validator, 1.2 already supports extensions. I'm not that familiar > with Validator, so I don't know what issues are preventing that version's > release, nor if the extends feature can be applied to the 1.1.x versions. > > Hubert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
