email validation in jspx

[fastmap]

<field:input field="email" id="c_com_mytest_email" max="30" required="true" validationMessageCode="field_invalid_email" validationRegex="\\b[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}\\b" z="some_z_value"/>

does not validate the email.... if the format is incorrect

[delgad9]

Alternatively you can use jsr 303 @Email annotation on entity email field...

......
    @Email
    @NotNull
    private String email;
.......

Roo will take care of the rest.

Hope this helps you

jD

[fastmap]

This is still a bug. The dijit javascript does not verify the pattern.

How do you get @Email from the roo field definition.

[delgad9]

FM,

Roo uses mostly sever-side validation (ssv) -via jsr 303-...

This is exactly what I am suggesting you to use for your email field validation.
Now: I just checked my code where I used it and I noticed that I am using

org.hibernate.validator.constraints.Email

class; which is not exactly part of current 303 and it works fine to me with Roo. The jar used is from the same people that speced and implemented JSR 303.

If you are interested in ssv vs client-side -from you original post it seems that you were trying such-. Let me know and I'll send everything you need to work ssv.


Thx
jD

[fastmap]

I primarily wanted client side validation. Roo takes in a regular expression on the field command and dos nothing about it on the client side is a bug.

If you wanted users to use jsr 303 email validation, provide a --email option on the field string command.

[Stefan Schmidt]

Yes, the client side validation does not currently take the regular expression into account. There is a Jira ticket for this here https://jira.springframework.org/browse/ROO-1695 with a working attachment I believe. I just need to find the time to apply it and test it .

I am not sure you should be using the hibernate validator @Email type given that this is not standardized. You can use the @Pattern annotation instead or create your own @Email annotation. This would future proof your app in case Roo you want to swap out the JSR 303 implementation at some stage.

[delgad9]

I am not sure you should be using the hibernate validator @Email type given that this is not standardized. You can use the @Pattern annotation instead or create your own @Email annotation. This would future proof your app in case Roo you want to swap out the JSR 303 implementation at some stage.
Reply With Quote

Is not Roo Spring 3.x complaint?

Based on Juergen Hoeller Spring and Java EE 6: Synergy or Competition? http://www.infoq.com/presentations/Spring-Java-EE6 great presentation on min 37. it is fine to use JSR 303 in combination Hibernate Validation 4.1. On the other hand: It is completely unlikely that JSR 303 would be dropped since is a critical part of EE6. Reality is Roo is part of EE6 ecosystem


Thx
jD

[Jack Punt]

Just to confirm that the input.tagx in ROO-1695 does work.
Some examples:

	<!-- prefer client to pre-validate the email -->
        <field:input field="email" id="c_my_pkg_domain_Member_email"
	         validationRegex="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}" />

        <field:input field="username" id="c_my_pkg_web_JoinForm_username"
					 validationRegex="[a-zA-Z][a-zA-Z0-9._-]{2,}"
					 validationMessage="begins with letter, limited special chars"
					 required="true"/>

        <field:input field="newpw2" id="c_my_pkg_web_UpdatePwForm_newpw2"
					 label="Confirm Password"
					 type="password"
					 validationRegex=".{6,}"
					 validationMessage="at least 6 characters"
					 required="true"/>

[Stefan Schmidt]

@delgad9

If you read my message carefully I am not suggesting for you to remove the dependency on JSR 303. That is the standard after all and Roo will keep supporting it for JPA based apps. This is very much in line what Juergen said.

What I have suggested is to not tie yourself in to a specific implementation of that specification. You would do that by using anything out of the org.hibernate.validator package because that is Hibernate Validator - an implementation of JSR 303. If you want to swap that out for another implementation of JSR 303 you can only do that without pain if you don't use 'extra' features which specific implementations offer.

This is similar to Roo's use of JPA instead of using Hibernate, EclipseLink, OpenJPA or DataNucleus directly. Since they are all JPA compliant you can simply swap them out with a single command.

-Stefan

[delgad9]

Hi Stefan,

Two (2) quick points:
1) For the forum members interested in fields validation issues, jsr 303 and why server-side validation is part of Roo. Could listen to http://java.dzone.com/articles/bean-...t-us-%E2%80%93 interview. It think is real good.

2) Some of the JPA complaint providers -specially Hibernate- include additional features beyond the required by the spec. You can leverage such functionality for the sake of given value to your implementation/product. Wouldn't you use such "non-standard" functionality for making you product faster or your code cleaner and maintainable?. If you don't, I bet you, your competition would do it. The notion of "standard" in the open-source world is: Users don't get locked with very few options or one implementation at all. At the same time it encourages the notion of best-of-breed. Providers could/should/have-to develop "differentiators" for the sake of delivering competitive complaint products.

Standard is important but implementations is what is going to make the difference in the final product. If there is a @Email annotation for validating an email field for the grabs that works like charm. I will use it.


Thx
jD