On Thu, Apr 14, 2011 at 12:18 PM, Aner Perez <a...@ncstech.com> wrote: > It's annoying because it uses a side effect to figure out if validation > failed. > Instead of setting some flag when any validation fails and using that flag > to determine if the INPUT result should be displayed, it is using the number > of error messages to determine if there were any validation errors.
A flag is a side-effect too; any non-local phenomenon is a side-effect by definition. > It violates the principle of least surprise because the action method got > called and it returned a result. This is the result the programmer expects > to be rendered. Especially if there were no validation errors, only error > messages added by the application code. I have some sympathy for this argument and will update the documentation to make the behavior clearer. Ultimately, if errors are detected, IMO the workflow interceptor is doing the right thing: how the errors are indicated seems to be a non-issue, other than a need to clarify that errors are indicated by the presence of error messages. I haven't had a use-case where the presence of errors means that processing should continue as normal (and the framework provides a trivial workaround when it does), but I agree it should be spelled out. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
