On Tue, 2004-10-12 at 11:27, Joe Germuska wrote: > >>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.)
Yeah. I investigated after I posted the question, and now have a much clearer picture of the current status of the Config package and how I'd like to see it migrate in the future. I did find an intermediate (and elegant) solution to something I was trying to do -- more details to follow about this another day ;-) > >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. What I'm thinking should definitely be sloted for a 2.x release. IMO, anything that breaks backwards compatibility with the config files should be a major version change 2.x. Now, that doesn't mean there shouldn't be change's that move towards a better pattern. > >- 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. I would guess "name" for form came in at the very beginning when there was a 1-1 between form and action. But that's just a theory. I would prefer to see "form" as well. I don't have a problem with "name" being used as a unique ID. That's what I think about when I see that attribute. Obviously, in the case of Action Mappings that is not the case. - Mike > > > -- > 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]
