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?
There is a standard digester rule which interprets the XML <set-property property="foo" value="bar" /> which is valid in the DTD where appropriate -- so rather than adding arbitrary attributes (which wouldn't validate), you add a "set-property" element. (This is implemented with a series of consistent digester rules in o.a.s.config.ConfigRuleSet, not with a wild-card path match, but it is configured where it is appropriate.)
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.
Agreed. It would take a fair bit of effort to change this without breaking all the world's config files, but it is a noble goal. Since "type" already has a meaning, there's no easy way to do this gradually.
- 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.
plugin would be easy enough to fix, since it doesn't use 'type' Unfortunately, XML config files wouldn't trigger deprecation warnings, but perhaps some warn-level logging could help alert people that they are using something slated for removal.
Which do you mean by "action forward"?
- "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've never liked the use of 'name' in ActionConfig -- I'd prefer "form" or "formName". I'm not sure if anyone else has a good reason why it is the way it is. "name" is used in many places in Struts as a "stand-in" for unique ID, so I'd go along with changing that in ActionConfig, which is doable in the same way that plugin could be changed.
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
