I'd like to see what our current chain would look like using an expression language like JEXL.
Don
Joe Germuska wrote:
At 10:26 AM -0800 2/20/05, Don Brown wrote:
Ah, we finally stumble onto the very slipperly slope that is conditional support for commons-chain. As we put more and more code into chain, we will inevitably have commands that only need to execute under certain conditions. There are three possibilities:
1. Bury conditional logic inside the command itself. This is the approach many of the current chains take, but has the disadvantage of the flow being very unclear to the reader of the config file, requiring digging into the source code.
2. Create an "if" command, which then would logically lead to a "switch" command and perhaps a "for" command. These commands would check certain conditions then execute configured commands based on the outcome.
3. Modify the XML so that the branching code is described as XML elements. While this option produces the clearest code, it also brings all the problems of something like Jelly with it.
So far, chain has resisted conditional support for the very reason it opens up a huge can of worms. However, as soon as you start putting complex logic in commons-chain, you are going to run up against the problem again and again, and I think solution 1 will really start to be inadequate. Solution 2 feels like a hack, and solution 3 (executable XML) has been shown a bad idea through Jelly.
I wonder what a merging of commons-chain and a scripting language like beanshell would look like...
Well, I've mentioned a couple of times about using JEXL for expression evaluation; it's a small step down that path, but also one with natural boundaries which might prevent one from trying to do *too much* in the config, rather than in the commands themselves.
In any case, I think (1) is not only inadequate, but wrong. I can see one command having some condition built into it, but I think once we have three commands which all have the same test ("if form is valid") then that's a sign that the logic is in the wrong place.
(2) may be a bit of a hack, but it avoids the slippery slope of (3). I've written a simple ConditionalLookupTag to address the specific case at hand. I think it would be more elegant using an expression language, but I still don't feel ready to push my "gee, JEXL is cool" bug into a dependency for either Struts or commons-chain just yet. I still haven't decided yet even whether or not to commit this for Struts. I wanted to simply have a single "abort chain if form invalid" command, but then I realized that returning true from a subchain aborts the entire chain-of-chains, at least using the base LookupCommand.
At 1:37 PM -0800 2/20/05, Dakota Jack wrote:
I find this discussion a bit confusing. Is this about the supplanting of implementation code of RequestProcessor with a chain? Is this about adding condition support in commons-chain to commons-chain or to Struts? I will assume the latter. Accordingly, I will assume that "chain" means "struts-chain".
If I understand things correctly, there are other alternatives than Don suggests. My thing, of course, is that the "other alternatives" are preferrable. I would suggest, at a minimum, that there be a standard plumbing chain. If someone wants to change that and to use XML, I would strongly suggest that that plumbing XML be kept strictly separate from the application struts-config.xml file.
Jack, I'm not really following you. For me, I simply raised the issue that there is a standard conditional case in processing a request for Struts: if the form is valid, then do a few things; if it is not, do a few other things (well, just one, "SelectInput") So I guess this is talking about something which belongs in the "standard plumbing chain."
I don't see a clear way to apply the Strategy pattern to this specific question, but maybe I'm just missing something.
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
