UserForm- Confirm Password Validation Problem

[Taras]

Hello:)
I have one small problem with Spring validation

I am writing simple application with Spring+Hibernate+Ajax
There is ApplicationUser table in DB. It has next fields:


userId;
username;
password;
firstName;
lastName

So I created ApplicationUser object with the same fields.

And I have next registration form :
username;
password;
confirmPassword;
firstName;
lastName;

<form:form commandName="applicationUser" method="post" id="userForm">
<form:input path="username" id="username"/>
...
<form:input path="password" id="password"/>
...
<form:input path="confirmPassword" id="confirmPassword"/>
...
<form:input path="firstName" id="firstName"/>
...
<form:input path="lastName" id="lastName"/>
...


I need to validate it using my validator
public class RegistrationFormValidator implements Validator {

public boolean supports(Class clazz) {
return clazz.equals(ApplicationUser.class);
}

// ect

The problem is in validating confirmPassword field because command object ApplicationUser does not have such field. How can I solve this problem without adding new properties to ApplicationUser class, and without JavaScript validation ?

Thank you

[dr_pompeii]

How can I solve this problem without adding new properties to ApplicationUser class, and without JavaScript validation ?
according to
http://www.springframework.org/docs/api/org/springframework/validation/Validator.html

void validate(Object target, Errors errors) is the unique way of implementation of validate object, i thought about a HttpRequest Object to resolve this, but not exists

it seems that you must add the not desired field in your class, is it critical or dangerous???

i dont think so

regards

[JEisen]

If you're binding to the command object, you need to have the field in the object. Well, what you really need is a setConfirmPassword() method -- this may be more acceptable. You may want to try something like this in your command object (note that this requires you to always have password above confirmPassword in the list -- I'm fairly sure Spring guarantees this order to be upheld, but if not, you'll have to do some tricky coding to check for null before doing this):


public void setPassword(String password){
this.password = password;
}

public void setConfirmPassword(String password){
if(!password.equals(this.password)){
this.password = null;
}
}


But realistically, I'd do it in Javascript. There's no need to send the page to the server when you know it'll be rejected because the passwords don't match. You could even do some nice little onBlur() event which enables the Submit button only when the two fields match.

[Jörg Heinicke]

You may want to try something like this in your command object (note that this requires you to always have password above confirmPassword in the list -- I'm fairly sure Spring guarantees this order to be upheld

How can Spring guarantee this?? What Spring gets is just a list of request parameters. There is no meaningful order for request parameters. Furthermore, even if there would be an order you had to rely on browser behavior (creating the request) and application server behavior (parsing the request).

Back to the actual issue ...

The problem is in validating confirmPassword field because command object ApplicationUser does not have such field. How can I solve this problem without adding new properties to ApplicationUser class, and without JavaScript validation ?

Why don't you want to add a property to ApplicationUser? There is no need to map this field also to the db, so it does not hurt at all.

Another approach is to use a DTO, but that's probably only overhead for a "simple application" where your ApplicationUser is probably not much more than a DTO itself.

A third solution is to implement this validation in onBindAndValidate() (http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/web/servlet/mvc/BaseCommandController.html#onBindAndValidate(javax .servlet.http.HttpServletRequest,%20java.lang.Obje ct,%20org.springframework.validation.BindException )) in the controller. It's called after the "normal" validation and gives you access to the request and so the confirmPassword request parameter. I discourage you from doing it this way though.

Joerg

[Taras]

Thaks for help:) I have added "confirmPassword" property to ApplicationUser class.

But I have one more question.
Imagine - there is form with a lot fileds :

username;
password;
firstName;
lastName
email
addresses
hobbies
...
etc

This is values from different db tables. Should I use ApplicationUser as command object and parse it( get it nested properties) on jsp page. Or may be it is a good practice to create a form class with all needed fields (like FormBean in Struts) and make it command object?
Please advice...

[JEisen]

How can Spring guarantee this?? What Spring gets is just a list of request parameters. There is no meaningful order for request parameters. Furthermore, even if there would be an order you had to rely on browser behavior (creating the request) and application server behavior (parsing the request).


You're right -- after looking it up, while the HTTP/HTML specs require that form data be sent in the order in which it appears in the document, the server is not required to process it in that order. The servlet spec specifically returns the parameters as a Map, so order is not guaranteed.

So if you had wanted to take this route you'd have to do checking to see whether password or confirmPassword were called first. Either way, looks like you've chosen a solution!


This is values from different db tables. Should I use ApplicationUser as command object and parse it( get it nested properties) on jsp page. Or may be it is a good practice to create a form class with all needed fields (like FormBean in Struts) and make it command object?
Please advice...


I would create a form command object that transports the data between the page and the controller where it can be broken up into the data types needed. In fact, I tend not to use data types as my form command objects in the first place (unless it's really simple) -- I'll have a POJO to just transport the form data back to the controller which then does the processing to put it in the appropriate entities before putting it in the database.

[Jörg Heinicke]

This is values from different db tables. Should I use ApplicationUser as command object and parse it( get it nested properties) on jsp page. Or may be it is a good practice to create a form class with all needed fields (like FormBean in Struts) and make it command object?
Please advice...

There have been a lot of discussions (http://forum.springframework.org/showthread.php?t=40207) (you'll find more than this one) whether you need a DTO or can make your entity available to the web layer directly. Since there is no final outcome it's up to you end the end which road to take.

If the object is filled by multiple tables does not matter at all. This detail is hidden in the data access layer. If in your case the user object for example has a list of address objects it's reasonable to crawl this list in the JSP IMO.

Joerg