Jing Zhou wrote: > > ----- Original Message ----- > From: "Paul Speed" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Monday, October 06, 2003 5:58 PM > Subject: Re: Struts-chain Behavior Discussion > > > > > > > Jing Zhou wrote: > > > > > > ----- Original Message ----- > > > From: "Paul Speed" <[EMAIL PROTECTED]> > > > To: "Struts Developers List" <[EMAIL PROTECTED]> > > > Sent: Monday, October 06, 2003 3:40 AM > > > Subject: Re: Struts-chain Behavior Discussion > > > > > > > > > > > (1) LookupCommand > > > > (2) ExceptionCatcher > > > > (3) SelectLocale > > > > (4) Process Action > > > > (a) SelectAction > > > > (b) CreateActionForm > > > > (c) PopulateActionForm > > > > (d) ValidateActionForm > > > > > > If validations fail in (d), the (e) and (f) are not necessary. > > > > Right, but then it can just stop that particular chain. I was under > > the impression that a chain can be aborted. If validation fails > > then the "Process Action" chain could abort and the main chain would > > continue on to "PerformForward". > > > > Incorporating Craig's comments about "SelectInput" on validation > > failure are left as an exercise for the reader. ;) > > I see what you mean. But the complexity is roughly the same > as or more than the original one in chain-config.xml. What I am > looking for is a simpler syntax to do the same thing without explicitly > defining possible nested chains. See my previous message, an example > is given.
It's not so much about "complexity" as it is readability. In the above example, the main steps are pretty clear: (1) LookupCommand (2) ExceptionCatcher (3) SelectLocale (4) Process Action (5) PerformForward (For clarity, I might even lump the first three into their own chain.) If I care what Process Action is then I can see the detail. Goto's were deemed dangerous because of the behavior that they hide. They obfuscate the flow of the code. It's not really any different here either. > > <command jumpLabel="L1" className="Class1" /> > > <command jumpLabel="L2" className="Class2" /> > > <command label="L1" className="Class3" /> > > <command label="L2" className="Class4" /> I had a longer response prepared to your other post, but decided it was too wordy. :) One example where the obfuscation comes in is that I had to look at it for a bit before determining that Class4 was always run. If a few more commands are thrown in, it really gets confusing. -Paul > > > > > -Paul > > Jing > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
