FormAction or Validator for this situation?

I was under the impression that validators were only to be used to validate that submitted data was within domain boundaries instead of validating against a database or other data-store. To that end, I added some new events to my FormAction which further processed the submitted data against the database. However, since some of this processing is similar to a validator, this seems like the wrong place for such information.

For instance, in a form a user enters an email address (which is the unique log-in name in the database) and indicates that they are a new user. The user does not enter a password, so this is valid data and passes the validator. Next the flow proceeds to an action-state which calls the FormAction. Inside this state, we check the database to see if there is already a user that has the email address entered previously. If so, we return an error and tell the user that the email address already exists, and help them to recover their password.

To me, this is barely different than a validator, but does more than validate superficially.

Should I be placing this code inside my validator, or is there a better overall method for performing these actions? Having to manually call the form and error array out of the context seems a little redundant for something I assume is fairly common.

Well, there is a subtle issue here.

Let's say this logical operation you're invoking has validation logic that is just one part of a larger unit of work -- a transaction. Transaction boundaries are typically defined at the service-layer, not the web-layer where the Spring validators are invoked as part of a validation workflow.

So I prefer for transactional validation logic to stay in my service-layer, and in that case I'd invoke the service-layer method from a action method to be called after syntactical binding and validation (perhaps with a Spring validator, or via configuration of the data binder).

But nothing says you can't put whatever you want in a Validator implementation. Just keep the point about transactions in mind.

Keith

Good point about transactions. I was planning to add transactions later and would definitely have missed this issue until then if I kept thinking in the manner I was.

I'm having a little difficulty understanding what the service layer is. I have my business layer (User, UserManager), and persistance layer (UserManagerDao, UserManagerDaoImpl) ala iBatis, and my web layer (OrderActions, OrderValidator) ala Webflow. How does the service layer fit into all this? If I'm just missing some synonym for something I've already named, this is wholy confusing!

Service layers are just architectural boundaries. They can be used to enable communication between dispersed development teams.

Another interpretation is that they are APIs which provide services, so your *Manager might be considered a service layer.

At least thats my understanding of them ;)

Expect a flame war....