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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
