Alan and I already talked offline, but I told him this
might be a good place to get other opinions.  I think
that all validation errors are fatal.  If it isn't
fatal it is really a message, so you could use
ActionMessages instead of ActionErrors.  The
equivalents of all the error methods could be made to
populate ActionMessages instead of errors.  This would
involve no change in the current framework.

Comments.

David

--- Alan Bowsher <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> This deals with the Struts Validator, and is a
> suggestion for a minor
> enhancement/extension.
> 
> The application I'm working on needs to be able to
> distinguish between
> 'fatal' and 'non-fatal' validations (for lack of a
> better term).  Fatal
> validations mean that the page should not be
> submitted.  Non-fatal
> validations mean that the user should see the
> errors, and be given the
> option to submit anyway.  This comes from a
> requirement for the user to be
> able to save partially completed work so they can
> come back to it later.
> Fatal validations are those that simply must be
> there in order for a
> successful database save to occur (key fields, etc).
> 
> My suggestion for handling this is to use all the
> same validation code, but
> change the type of message returned depending on the
> error level.  This
> could be done either by subclassing ActionError and
> adding flags for the
> level of error, or by returning ActionMessages in
> the non-fatal case.  Our
> base action class could then run the validator and
> take action based on
> what came back (a single fatal error would trigger a
> fatal response).
> 
> In the validation.xml, the user could specify things
> such as 'required'
> (the non-fatal version) and 'requiredFatal' to be
> run against the various
> ActionForm fields.  The validation definitions could
> use the same method,
> but pass in some sort of flag that just gets passed
> along to the
> lower-level utils to return the right type of
> message.
> 
> It would be easy to implement this myself but I'd
> rather stick to a
> standard solution, if this idea has any merit for
> anyone else.
> 
> Thoughts?
> 
> Thanks,
> Alan
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 


__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to