Good catch. I inherited the form property config class, but not its properties, and I was thinking that the FormBeanConfig instance would already be using the custom class, if any. Now I'm seeing that's not necessarily the case.
When the extensions are being realized, what we'll have on hand is what Digester'll give us, and that's what's explicitly specified in struts-config. In order to inherit the FormBeanConfig subclass, we can either (1) recreate it and re-register it using the inherited subclass, or (2) let the custom digester rule handle it. (1) is doable, but with (2), I'm beginning to hear the words slippery slope again. (Wasn't that phrase was uttered here just recently?) For the subclass' properties, I'm not sure how to access those yet. A straight copyProperties could override props we want to retain. I don't want to support this unless it can be done properly, and to me that means inheriting only values that were specified in the config, not properties that could've been set by other means. Perhaps this "extends 1.0" could concentrate on the form bean being configured, as opposed to the object used to configure it? I agree it would be a bigger issue for mappings and forwards. I'll continue to look into a clean way to accomplish this. Suggestions would be great. As for modules, my inclination is to limit inheritance within the module. IIRC, this would match the way global-forward and global-exception works. Feels cleaner, too. I'm not sure which config elements are shared across modules, or by the default to the sub modules. However, it won't be that difficult to inherit individual elements from the default module. That might lead users to asking for the entire <action-mappings> or <form-beans> to be inherited! :) Hubert 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]
