If we pull off extends for individual config elements, maybe extending a base-config.xml would be as simple as referring to it in each of the modules' <init-param> in web.xml.
- Hubert On Tue, 22 Feb 2005 09:27:27 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I don't know about extending modules, but it would be nice to extend > other Struts config files. Define a base-config.xml that isn't used > directly then inherit it in several modules. > > Don > > Niall Pemberton wrote: > > 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] > > > > --------------------------------------------------------------------- > 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]
