Joe Germuska wrote:
At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
Ted Husted wrote:
That would be nice, and does make a lot of sense. This could lead to the standardization of attribute names such as "className" a.k.a - "type", "processorClass", "handler".... :-)On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
Another simple suggstion I would like to make (enhancement request) -
it would be extremely powerful to add the property support that
exists for plugin configuration, to action and request processors. This can go along way for special purpose actions. The parameter
attribute is ok - but too limiting (IMO).
Sounds good to me. You should file this with Bugzilla and attach a patch if you can.
A related enhancement, which is long overdue, is
* Enhance all configs to extend one configuration element from another, as is done with Tiles Definitions
I'd dearly love to see a patch for this enhancement. It would make such a difference in so many Struts config files. And now that we're in the 1.3 zone, the gloves are off :)
I'm pretty sure that Ted was talking instead about inheriting configurations. For example, you could have an "address" dynaform that you extended so that various forms which all had common street/city, etc fields wouldn't require them to be redefined, and then you could extend the validation rules also, so that your rules would be consistent without duplicate configuration code.
ahh.. I see. I misread that.
Note that, at least with ActionConfigs, there is an important difference between "type" and "className". "className" refers to the type of the ActionConfig itself, should you want to use a subclass (say, for custom properties) while "type" refers to the type of the Action which will be created to service the ActionConfig. This can be confusing, but they aren't synonymous. I'm not sure that I think that the other cases where you've named attributes shoudl all be standardized either, but maybe if it were laid out in front of me as a proposal, I'd think harder about it...
Hmmm... I wasn't aware you could specify an ActionConfig class (subclass). In fact, I wasn't aware you could specify the className for Form, Controllers, or Actions at all :-). How does this attribute work with digester rules, dtd validation, etc?
I guess in this light, things are a bit different. I do still feel there are some inconsistencies though. Some thoughts
- the use of "handler" in the exception element seems inconsistent. IMO it would be more consistent to use "type" as the exception handler class, and add an attribute "match" or "exceptionClass" for the registered exception.
- in datasource, form, controller, message-resources, form-property and action: className refers to the Config class. But in plugin, and action forward: className is the type to instantiate.
- "name" is something I always felt was inconsistent. action refers to the associated form bean, but in form bean and action forward elements name is the unique identifier.
I did notice that there is a "set-property" mapping for all elements (even form-properties which is a bit strange :-). Does this work like it does in the PlugIn class for actions? I never noticed it before. That's basically what I was referring to originally and I see the dtd already supports it.
- Mike
Joe
- Mike
-Ted.
--------------------------------------------------------------------- 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]
