Announcement Announcement Module
No announcement yet.
Validation concept questions Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Generally, the first part sounds ok. I am not sure what distinction you see between a pojo validator and a service. Here's how I would describe what should be going on:

    1. Have a ZipCode class whose constructor and seZipCode(String) methods will throw an exception (RT) if a non-empty string is provided that does not match the zip code regular expression (defined within the ZipCode class as a private constant.) If that exception is thrown during the field binding, your framework will catch it and produce an error message, as you are saying. (If you use Spring validation, the error message key generated by Spring in this case will contain "methodInvocation", e.g. you can use the following property in you file:

    methodInvocation.zipcode=Invalid Zip Code entered. Please specify a 5- or 9-digit code.
    The point here: you will never have a ZipCode object in your system that is totally out of wack. It will always be either an empty code (may be valid for some of your forms) or a 5- or 9-digit code. (Now, that code may or may not represent an actual US zip. To verify that, you will need an external service (such as AMS, or something like that) to which you will need to pass the code to be matched against the data base of the existing US zip codes.)

    2. In the presentation tier, I would have a form validator - that implements Spring's Validator - that validates all fields in the form on submission. It may use individual re-usable field validators for the fields whose validation is not trivial most likely will be used by other forms and applications. You may want to invoke each of such specific validators for each field individually - e.g. on blur, if you use Ajax/JS, etc. For example, let's say, you want to have a Zip validator that not only checks the input string for matching the regex, but also disallows empty zips and zips that do not exist (not registered with the USPS.) Such zip validator will receive a valid ZipCode instance (we know because there may not be an invalid instance thanks to the way we have implemented ZipCode) and will check if the stored string is not empty. If it is, I would add an error to the Errors object that Spring passes to the validator. That's it. The form bounces back and the error tag displays the error associated with the field. No need to throw an exception in this case. I am not sure about the JSF specifics. If it expects you to throw a validation exception to display the error, fine.

    3. Now, if you indeed have another validation requirement - to ensure that the zip code is an existing US zip code, you need to call a generic (non-presentation-tier) service to do the checking. However, it would be appropriate to initiate that call from your presentation tier validator. For that, your presentation-tier validation object must be injected with a reference to your generic middle-tier "Address Management Service".

    So, you'd have something like this:

    public class MyZipValidator implements Validator {
        private AddressService addressService; // ref to implementation of AddressService interface
         * Sets a reference to the given address verification service that will be used
         * for the actual verification of the zip code against the database of known zip codes.
         * @param svc address verification service implementation
        public setAddressService(AddressService svc) {
            addressService = svc;
        public boolean supports(Class aClass) {
            return ZipCode.class.equals(aClass);
        public void validate(Object obj, Errors errors) {
            ZipCode zip = (ZipCode ) obj;
            if (zip.isEmpty) {
                  rejectValue("zipcode", "empty", errors);
            } else {
                  verifyZipCode(zip.getCodeAsString(), errors); 
         * Verifies the given zip code string using the external address verification service, 
            and updates the errors objects if the code fails to verify.
        private void verifyZipCode(String code, Errors errors) {
             if (!addressService.zipCodeExists(code)) {
                 rejectValue("zipcode", "nonexistent", errors);
    Last edited by constv; Nov 20th, 2008, 09:34 AM.


    • #17
      Nono my problem at the moment is the fact that most of the discussed was about Object/Form validation and JSF only supports field validation.

      Means that JSf itself has a validator interface that has a method getting the specific UIComponent that is the input text field itself as a component. This makes it also possible that a specific error message is displayed and bound to that specific component (input text)

      If i do object level validation however, which makes sense to validate Domain Objects, i would be able to validate the whole set of fields and would also be able to see dependencies between fields etc.

      So the conflict here is that i first have the requirement to validate JSF forms with its own interface that throws a ValidationException and my Domain Object Validation model that could follow Springs validator interface and would validate my Domain Objects.

      With JSF there's the possibility to write a ZipCodeValidator with a validator method that does nothing but validating a ZipCode field.

      I mean what i could do is to write a Spring Validator and give the UIComponent as object to be validated and validate only the value of the input field.

      The only clear solution in my mind is to follow the JSF validator interface and do the ZipCode validation there and attach this validator to each of the UI Components that need to validate a ZIP Code and have my Domain Object validator that will then again validate the integrity of the Domain Object, which could care about the dependency between fields etc.

      What do you guys think about that?


      • #18
        There is given a good questions for validation.