struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: Roadmap
Date Tue, 12 Oct 2004 15:27:50 GMT
>>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            
Joe@Germuska.com  
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message