Announcement Announcement Module
No announcement yet.
email validation in jspx Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • email validation in jspx

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

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

  • #2
    Alternatively you can use jsr 303 @Email annotation on entity email field...
        private String email;
    Roo will take care of the rest.

    Hope this helps you



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

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


      • #4

        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
        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.



        • #5
          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.


          • #6
            Yes, the client side validation does not currently take the regular expression into account. There is a Jira ticket for this here 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.


            • #7
              Roo and EE6 ecosystem

              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? 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



              • #8
                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._%+-][email protected][a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}" />
                        <field:input field="username" id="c_my_pkg_web_JoinForm_username"
                					 validationMessage="begins with letter, limited special chars"
                        <field:input field="newpw2" id="c_my_pkg_web_UpdatePwForm_newpw2"
                					 label="Confirm Password"
                					 validationMessage="at least 6 characters"
                Last edited by Jack Punt; Dec 8th, 2010, 05:18 PM.


                • #9

                  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.



                  • #10
                    Roo and EE6

                    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 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.