<snip> Didn't your O-O programming classes explain to you the evils of the "goto" statement? :-) </snip>
Of course everyone knows gotos are naughty. Thats why programming languages nowdays market them under the much friendlier sounding terms "break" and "continue". ;-> -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, 3 October 2003 12:48 To: Struts Developers List Subject: Re: [struts-chain] Writing a command to process a Tiles Definition Jing Zhou wrote: >----- Original Message ----- >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >To: "Struts Developers List" <[EMAIL PROTECTED]> >Sent: Wednesday, October 01, 2003 11:24 AM >Subject: Re: [struts-chain] Writing a command to process a Tiles Definition > > > > >>There's a "conditional behavior" use case in the existing code as well; >>when validation fails, we want to redisplay the input form. Originally, >>I modelled this command as a Chain that conditionally executed its child >>commands, but that seemed a little hokey. Now, this command definition >>says: >> >> <command >> >> >className="org.apache.struts.chain.servlet.ValidateActionForm" > > >> failureCommand="servlet-validation-failure"/> >> >>so I'm declaring the name of another chain to go execute if validation >>fails. The actual code that does the conditional execution looks like >>this (in the abstract base class): >> >> // Call the environment-specific protected validate() method in our >>implementation class >> ActionErrors errors = validate(context, actionConfig, actionForm); >> >> // If there were no errors, proceed normally >> if ((errors == null) || (errors.isEmpty()) { >> return (false); // Proceed with the main chain >> } >> >> // Execute the specified validation failure command >> try { >> Catalog catalog = (Catalog) >> context.get(getCatalogKey()); >> Command command = catalog.getCommand(getFailureCommand()); >> command.execute(context); >> } catch (Exception e) { >> ... deal with exception ... >> } >> return (true); // Terminate the main chain >> >>This approach seems more scalable -- for example, you can have several >>different conditional options, you aren't binding all the behavior >>definitions into a single chain definition, and you can decide based on >>your needs whether to return false or true from the main command (which >>dictates whether the owning chain thinks processing is complete or not). >> >> >>Craig >> >> >> > >I am wondering how I could implement a "jump behavior" in the main >chain. The use case for a "jump behavior" is that the main chain should >continue with several commands skipped over. For example, I would like >to jump to the last command in the main chain after the current command. >Any ideas? > >Jing > > Didn't your O-O programming classes explain to you the evils of the "goto" statement? :-) More seriously, if I was faced with that choice, I would refactor it into an "if" decision rather than a "skip" decision, just like I would refactor any code where a "goto" seemed like the right answer to use an "if" instead. Just because we're talking about scripting languages (which is what we're doing when we talk about using chain definitions as the definition of control flows) does not change the use of correct design principles. Craig --------------------------------------------------------------------- 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]
