I really like the annotation style of validation. But I've run into a little snag and can't seem to sort it out.
I have two forms:
The register action looks like this:
The User class contains the actual validations. Two things.
1) When I hit submit with wrong values, it performs the validation correctly, and attempts to return the "input" result. I'm using the convention plugin which I was under the impression made it so that when "input" is returned, it would automatically go back to the page with the form. This wasn't the case, I had to actually provide the mapping. Not a huge issue but annoying.
2) When there are field errors, instead of only applying to the form I submitted, they also attach themselves to the other form. Any tips on how to make this not happen?
1) The "input" result is the "input" result, whatever it's defined to be: there's no magic "I'm guessing what you mean by 'input'", and that would be potentially bad anyway, since people don't always want to return to the original form page.
2) S2 expects there to be either (a) a single form on a page, or (b) unique input names: it's just a map in the action--if you examine it you'll see the errors are mapped by field name, not some unique combination of form name + field name. I can think of a few possible solutions, none of which are particularly general-purpose, and still depend on *some* value coming in the request to uniquely identify the form. Other than the form's action, nothing comes by default in HTTP to identify what form made a submission.
Joined: Jul 13, 2010
1) I was incorrect about how the convention plugin operates. This is what it does; "The Convention plug-in finds this with the help of the result code returned by the Action class. If "success" is returned then the Convention plug-in will look for a file name welcome-user-success.jsp or welcome-user.jsp . It need not be a jsp file it can be even a velocity or freemaker files. If the result value is "input" it will look for a file name welcome-user-input.jsp or welcome-user-input.vm or welcome-user-input.ftl."
2) What are some of the solutions you can think of? In this case, it's a very simple matter to just change the name of the fields, but if I were using two classes, both requiring a User object, both using the model driven approach, then they would have the same field names because they would be determined by the User object. I suppose I could just make sure not to have these forms on the same page.
Or don't use model-driven and expose the user via different properties, like loginUser and registerUser. Those are much, much easier to implement than any of my more general-purpose ideas, which would require either a theme change or a hidden value, a replacement params interceptor, and a validation tweak, or some combination thereof. They're not bad ideas, they're just impractical for a one-off solution.