Not that I am an expert, nor is this the Command Chain a major issue for me, but logic in configuration files (xml) is like writing LISP. For some it is a rare beauty, for others it foggy at best.
Edgar > -----Original Message----- > From: Paul Speed [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2003 7:57 PM > To: Struts Developers List > 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 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
