Yes, I like this better. Then, a method on ActionConfig:
public String getProperty(String key)
which returns the value which was set.
As an implementation detail, there would also be a setProperty(String key, String value). This method would obey the "configured/frozen" semantics of other properties of ActionConfigs, so that users don't mistakenly change values during runtime on a shared object.
I think I like Martin's proposed configuration syntax also. I suppose it could be confusing in some ways, but I think those who need to use it would figure it out.
I'll probably do this in the next few days. Thanks for the opinions...
Joe
At 8:30 PM -0800 11/30/04, Martin Cooper wrote:
I like the idea of having a mapped property like this, but I'm not sold on this particular mechanism for implementing it. The reason is that it takes the general purpose <set-property> element and makes a particular property name "special". That doesn't seem very clean to me, and we could end up breaking apps where people are already using a 'props' property.
I'd prefer to use a new element nested within the action element for this, or perhaps even better, enhance the existing <set-property> element to handle it. The latter would allow the same mechanism to use used anywhere we currently allow <set-property> to be used.
One example of how we might do this:
Do things the way we do now (i.e. a custom property): <set-property property="foo" value="bar"/>
Set a mapped property instead of an individual one: <set-property key="foo" value="bar"/>
Notice the use of 'key' instead of 'property' to indicate that this will land up as a key/value pair in the mapped property set.
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
