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. -- Martin Cooper On Tue, 30 Nov 2004 16:05:16 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Sure, works for me :) > > Don > > Joe Germuska wrote: > > > <snip /> > > > > Now, then: This whole thread started as a different question and was > > motivated by an earlier question. Assuming that we continue to use > > Digester to instantiate and populate ActionConfig objects, I would > > like to add a "generic" mapped property to ActionConfig so that rather > > than writing trivial and boring subclasses of ActionConfig, one can > > simply set properties on it. I'd make it a Properties because I'd > > expect it to have strings, but I would accept arguments to make it a > > map instead with the idea that later other Objects might get in > > there. (Ugh, but all that casting!) Assuming no one objects in the > > next day or two, I'll assume it's ok, and I'll call it "props", just > > because I would rather not screw around waiting for another name. > > > > The motivation for this was a perceived flaw in the ChainAction and > > chain DispatchAction classes which won't know in which catalog to look > > for the command either one is supposed to execute. A generic property > > map would allow the ChainAction to define the name of the properties > > it wants for its configuration, rather than requiring that its > > ActionConfig implement some specific interface just to get one more > > property in. > > > > Joe > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]