Eric Rank wrote: > However, I feel that it's sloppy because it requires additional logic. >
So does the request processor modification. I just have a base Action class that will forward to the input on a GET or validate and do the right thing based on the results of the validation. So, simplified, my subclasses may optionally override executeGet and/or executePost (although I actually have the equivalent of preprocessForm and postprocessForm methods, so I rarely need to do that) etc. This allows me to display the input w/o validation (default executeGet just returns the input forward), validate, call business logic, etc. and rarely have to think about anything (a Good Thing for me; thinking hurts). (Actually, in practice I'm using injectable processing units inside the actions, too, so I rarely change much in my actions at all, which is TWISB (The Way It Should Be.)) Dave PS It probably shows, but I actually spent more time trying to decide how to format that last ".))" than the rest of the email. Really, it should be ").)" but that's hogly, "))." looks nice but is wrong, as is my current solution. Pah. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
