---------- Forwarded message ---------- From: Sean Schofield <[EMAIL PROTECTED]> Date: Wed, 16 Feb 2005 09:28:55 -0500 Subject: Re: [chain] LookupCommand's return value To: Joe Germuska <[EMAIL PROTECTED]>
> Not changing as in breaking, but perhaps extending. What about a > property "ignoreReturnValue" which would always return "false" > instead of returning what the looked up command sought. That's what I figured you meant. I have no objection to adding another property like this. > Well, I have zero interest in developing any other expression parser, > so from there, I think you're limited to very crude things, like a > bunch of properties on a command that would specify context keys and > imply handling, like 'abortIfContextValueTrueOrNull' I will go one further. I have *less than zero* interest in developing another expression parser. ;-) > 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? > Joe sean --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
