struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: DTD 1.3
Date Mon, 02 May 2005 12:56:43 GMT
At 12:45 AM -0700 5/2/05, rmanchu wrote:
>hi
>
>>  PropertyMap? ConfigProperties?
>>
>>  Martin Cooper
>
>i think ProperyMap is a good name :)
>i need this in FormPropertyConfig badly :( :)
>
>>  I'm happy to see this general pattern extended to any config element.
>>  The cost is pretty low, and in fact, consistency would be nice - users
>>  shouldn't hav to worry about where they can use the "key" attribute in
>>  <set-property>.   Probably we should add some interface to cleanly
>>
>>  Joe Germuska wrote:
>
>in going thru the *.config.*Config classes i noticed that there is 
>no BaseConfig class. PropertyMap could be implemented in the 
>BaseConfig itself.
>
>quickly going thru *Config.java sources and DTD 1.3
>
>1) "configured" is common to all (i think)
>2) "extends" is common to all except FormPropertyConfig (2much work 
>4 too little result :)? ), can be over ridded to do nothing
>further,
>3) DTD attributes "className"/"type" : seems the meanings are 
>"interchangeable" for different elements (eg: form-bean.className vs 
>?(action.className || action.type)), no common get/set methods,
>but cannot change for compatibility issues?
>4) others?
>
>anyways, i was thinking of writing a BaseConfig to extend all 
>*Config classes. is this a good idea?

It seems a reasonable way to implement this shared behavior.  It only 
seems logical that people would expect various struts config objects 
to have common characteristics (as you did with the PropertyMap 
behavior).  I wonder if that would have helped with the inheritance 
mechanism at all, or if it has any impact on that.  I haven't really 
studied the implementation Hubert provided.

re (3), I don't think you'll find any places where "className" and 
"type" are truly interchangeable.  For <action>, the "type" is a type 
which extends o.a.s.action.Action, which will be used to execute 
action behavior; the "className" is a type which extends 
o.a.s.action.ActionMapping, which will be used to hold configuration 
properties.

This is confusing, to be sure.

Joe


>riyaz
>
>
>>
>
>
>Joe Germuska wrote:
>>This is true, for now, although one of the motivations was to make 
>>it possible for users to use the DispatchChainAction, which 
>>requires two config parameters (command and catalog) without 
>>binding users to a particular subclass of ActionMapping -- so it's 
>>entirely possible that Struts will begin using it.
>>
>>Just thought I'd point that out.
>>
>>I'm using it in development for non-framework stuff, though, and 
>>it's pretty handy.  I mean, what was more boring that writing a 
>>custom subclass of ActionMapping?  And also, in the chain model, 
>>you are much more likely to have multiple steps in the request 
>>process which each want per-action-mapping config details, so you 
>>would be likely to run into problems if each step required a 
>>specific type -- the inheritance hierarchy would become totally 
>>unmanageable.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message