commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: [chain] add expression evaluation?
Date Fri, 03 Dec 2004 12:39:06 GMT
My one comment this morning is that is looks like Martin is getting ready to tag and roll a
release, so of course we should wait for that to happen before committing any changes. 

If for any reason Martin is tied up, and people are chaffing to commit, of course I'd be happy
to step up.


On Thu, 02 Dec 2004 16:40:31 -0600, Joe Germuska wrote:
> In a discussion on the struts-user list, I got around to describing
> a configuration format which made me wonder if folks would tolerate
> some kind of expression evaluation engine in chain.
> The musing repeated below:
> At 1:57 PM -0600 12/2/04, Joe Germuska wrote:
>> I think you could find the view processor command by using the
>> standard Chain "lookup action".  Well, out of the box, its
>> "nameKey" property would depend on some String value being placed
>> into the context under a certain key, and as it is now, we're
>> talking about using a String property of an Object in the context
>> under a certain key.  If we gave the LookupCommand an expression
>> language (JEXL, perhaps?), then we could do something like this,
>> which seems cool:
>> <command
>> className="org.apache.commons.chain.generic.LookupCommand"
>> catalogName="struts-view-preprocess"
>> nameKey="${}" optional="true"/>
>> or possibly work some magic to make the "context" prefix assumed.
>> Anyone  have an opinion about adding a JEXL dependency to Chain,
>> or whether this would be best left to a Struts subclass of
>> LookupCommand?
> Ideas?  I'm not sure right now of the scope of this proposal -- is
> it just for the LookupCommand?  Is it somehow implemented more
> widely? How can you do that when Chain is first-and-foremost an API?
> I can certainly see some of these questions leading folks to throw
> up their hands and say "let's just keep it simple."  There's no
> critical reason to add this dependency to the core, but when you
> think about the expressive power it would provide in the config
> files, it seems pretty cool.
> Joe

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message