Re: Second call: add "generic" mapped property to ActionConfig

[Don Brown <mr...@twdata.org>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Second call: add "generic" mapped property to ActionConfig

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

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            
Joe@Germuska.com  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

Re: Second call: add "generic" mapped property to ActionConfig

[Martin Cooper <mf...@gmail.com>]

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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org