commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: Fwd: [chain] LookupCommand's return value
Date Wed, 16 Feb 2005 14:51:09 GMT
>  > Basically, the JEXL dependency would only be a runtime dependency for
>>  people who chose to use those implementations of commands which
>>  depended upon it.  We could have a subproject for "contrib" or
>>  something, but my feeling is that that's more trouble than its worth.
>>  If the binary JAR for commons-chain is readily available and the API
>>  has no dependencies, then why not include useful implementations in
>>  the same JAR with clear instructions on when they require auxiliary
>>  libraries?  Still, if people would prefer a commons-chain-contrib
>>  project, I wouldn't complain; I'd just want some opinions on where
>>  exactly to put it.
>I think the contrib thing would be overkill.  I agree with you there.
>Remind me again of why your use case requires expressions?  Wouldn't
>the ignoreReturn value attribute allow you to prevent the termination
>of the larger chain that the LookupCommand is contained in?

I blurred two things together; if one assumed (as I did) that 
LookupCommand always returned false, then it seemed reasonable that 
you might want to have a flexible way of aborting a chain which was 
looked up.  Writing a hard-coded class which simply tests the state 
of the Context seemed less than elegant.

I have also earlier envisioned a variant of the LookupCommand which 
was more dynamic in its lookup because rather than having a command 
name hard-coded, it could use an expression to retrieve the command 
name from the Context.  You can do this to some exent using the 
"nameKey" property and the CopyCommand, but I think it would be more 
flexible and more elegant with expressions.  A specific use case I 
had thought of for this before was the idea that you might, in 
Struts, define an entire catalog of commands whose names were 
potential values for ActionForward.getPath().  You could then use a 
lookup command to automatically invoke a command in that catalog if 
one matched the path.  You couldn't get this without a custom 
command, because Copy can only copy an object in the Context, not a 
property of an object in the Context.


Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

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

View raw message