The answer could be simpler than I originally thought, and it revealed itself in the code. Since a custom config object would have to extend the original, say FormBeanConfig, it would be up to the subclass to override the inheritFrom() method which is what actually copies config properties from another FormBeanConfig. Any subconfig could implement their own code to inherit their own custom props. The code that executes before inheritFrom() would have the responsibility of making sure that config object is of the right (sub)class.
On Tue, 22 Feb 2005 17:15:14 -0000, Niall Pemberton <[EMAIL PROTECTED]> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
