struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rmanchu <rman...@gmail.com>
Subject Re: DTD 1.3
Date Mon, 02 May 2005 07:45:50 GMT

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?

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


Mime
View raw message