Re: DTD 1.3

[rmanchu <rm...@gmail.com>]

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

Re: DTD 1.3

[Joe Germuska <Jo...@Germuska.com>]

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