All,
this may be somewhat OT, but it may be worth a short discussion (though this
message is pretty long) :)
We're using Struts (of course!) as part of a J2EE architecture that also
includes EJB. To clearly separate the validation processes, we use the
Struts Validator to perform the "first-level presentation" validations:
mandatory fields, valid dates, masks, numerics only and so on. Everything
works just fine. (Note: I don't really like Javascript so we decided not to
use it. :) )
We also have more "business-oriented" validations: for example, I'm trying
to create a new user, the "presentation details" are OK but the user ID
chosen already exists in the DB. This type of validation involves access to
the "real" back-end and goes through a relatively long set of calls
(delegates, EJB, DAO) and should not (in my opinion) be included as part of
the ActionForm validations.
It is important that the end user sees all the validation errors at once and
not in two waves (the first one for the data validation and the second for
the business validations once the data is correct), so the two processes
must be linked somehow.
I have implemented the following:
// Presentation validations
ActionErrors errs = myForm.validate(mapping, request);
try {
buzDelegate.validate();
} catch (ValidationException e) {
// convert business errors to ActionErrors and add them to errs
}
with:
buzDelegate.validate() throws ValidationException()
buzDelegate.buzMethod() throws ValidationException()
ValidationException
- errors: Collection
+ errorsIterator: Iterator
+ addError(ErrorMessage error)
In this way, the end user sees all the errors at once.
The problem is that the validation process is different depending on the
operation performed. For example, I can't create a new user with an ID that
already exists but I can only update an _existing_ user.. so I end up with:
buzDelegate.validateCreate(..) throws ValidationException
buzDelegate.validateUpdate(..) throws ValidationException
...
which I personnaly find _not_ clean at all... :(
A few questions:
- does this approach look "valid" (heehee) to you? Any suggestions about a
better approach?
- I have defined new classes ErrorMessages and ErrorMessage to separate the
fact that the errors come from different layers. In practice, ActionMessage
classes are not really related to Struts so they could probably be reused
for buz validations.
Any feedback is appreciated...
Thanks.
Andrej
