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]

Reply via email to