Interestingly, Digester already supports the expression replacement mechanics (see org.apache.commons.digester.Substitutor), so it ought to be really easy to do this kind of thing, and an elegant solution to boot.
I'm +1 for it.
Craig
I hadn't seen that -- and it's very cool!
But a quick look leads me to believe that it would be evaluated only once, at XML ingestion time, while in the context I'm thinking of, the value of the expression would be dependent on the runtime state of the context. With Chain, I think that would be very powerful.
Joe
On Thu, 2 Dec 2004 16:40:31 -0600, Joe Germuska <[EMAIL PROTECTED]> 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="${context.forward.name}" > 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 Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
