User input validation

Discussions

EJB design: User input validation

  1. User input validation (6 messages)

    Until now I've seen some user input validations in J2EE:

    1)Jakarta Common
    http://www.onjava.com/pub/a/onjava/2003/07/23/commons.html?page=4
    2)TSS User Validator Patterns
    http://www.theserverside.com/patterns/thread.jsp?thread_id=11947&article_count=29

    It seems that most of people are using user input validations in the presentation layer frameworks like Struts or directly in JSP files. My questions are:

    1)Is this the best way? For me all the user input validations should not happen at the presentation layer framework like Struts. Instead at DTO (or Value Object) or at the EJB Delegate, so you can use other presentation layer frameworks and reuse the user input validations. Like what these articles from Brett have shown:
    http://www-106.ibm.com/developerworks/java/library/j-ejb1217.html
    http://www-106.ibm.com/developerworks/java/library/j-ejb01213.html

    The problem with this approach is that it's just too complicated and forget the idea of KISS. Using descriptive approach (xdoclet and javadoc) can make the user input validations a lot more easier.

    2)Is there any descriptive (xdoclet or javadoc) Open Source libraries for handling such a user input validation? What I would like to write in my interface is just the following:

    public interface Person {
      public String getName();

      // @validator:mandatory
      public void setName(String name);

      // @validator:age > 0 && age < 100
      public void setAge(int age);
    }

    public class PersonDTO implements Person {
      // Just as usual...
      ...
      public void setName(String name) {
        this.name = name;
      }
      ...
    }

    I've seen these articles at JavaWorld "Design by Contract":
    http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-cooltools.html
    http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy.html

    and I think I can use the pre-condition for my purpose. Is there anyone has tried this before to use it as a user input validation?

    Any ideas? Thanx a lot!.

    Lofi.
    http://www.openuss.org

    Threaded Messages (6)

  2. Additional link about DTO validation[ Go to top ]

    One additional link about DTO validation:

    TSS:
    http://www.theserverside.com/patterns/thread.jsp?thread_id=13571&article_count=22
  3. User input validation[ Go to top ]

    I agree that the correct place to do you validations is in your JavaBeans (whether they are DTO or business objects themselves). The Jakarta commons Validator package is focused on this approach. I have a similar set of utilities in my own open source library: the "BeanFilter" package:

    http://chrysalis.sourceforge.net/apidocs/org/chwf/filter/package-summary.html

    I think the best way to configure validations is with external XML files rather than the XDoclet-style Javadoc markup.

    Also, the main challenge I have found to JavaBean-oriented validation (as opposed to UI-oriented validation) is generating error messages that are meaningful to the user. You have to think carefully how error messages in your bean layer are going to percolate up to your UI; one the main point of validations is telling the user how to correct bad input, not just preventing bad input from happening.

    None of this is easy. Every validation framework I have seen (including my own) is limited to single-field validations (max and min size, required, etc.). Things become even more challenging when your validation logic depends on more than one field.
  4. Validation and Business Rules[ Go to top ]

    Paul, thanks for a fast answer!

    <quote>
    I think the best way to configure validations is with external XML files rather than the XDoclet-style Javadoc markup.
    </quote>
    Why do you think so? I feel that Jakarta commons validator package with those XML is much more complicated to use and to handle. Check this article:
    http://www.onjava.com/pub/a/onjava/2003/07/23/commons.html?page=4
    and look how much code you really need just to validate that simple input. Using Javadoc/XDoclet style is quite simple, IMO.

    <quote>
    Also, the main challenge I have found to JavaBean-oriented validation (as opposed to UI-oriented validation) is generating error messages that are meaningful to the user. You have to think carefully how error messages in your bean layer are going to percolate up to your UI; one the main point of validations is telling the user how to correct bad input, not just preventing bad input from happening.
    </quote>
    Agree and also for multiple languages support. IMO, it would be nice if I can describe the validator with the exception its throwing. So, I can catch that Exception in my presentation framework and using Locale to give the best information about each exception. Example:

    public interface Person {
      public String getName();

      // @validator:mandatory throws InputException
      public void setName(String name);

      // @validator:minmax age > 0 && age < 100
      // throws MinMaxException
      public void setAge(int age);
    }

    -> In my presentation framework for "sequential" error handling:
    // Factory for the Person
    Person myPerson = Person.createPerson("...");
    try {
      myPerson.setName(null);
      myPerson.setAge(200);
    } catch(InputException) {
      ...
    } catch(MinMaxException) {
      ...
    }

    -> In my presentation framework for "total" error handling:
    // Factory for the Person
    Person myPerson = Person.createPerson("...");
    try {
      myPerson.setName(null);
      myPerson.setAge(200);
    } catch(ApplicationException) {
      // InputException and MinMaxException extend from ApplicationException
      // Use Business Rule Engine for "if then else" Exception handling
      ...
    }

    What do you think about this?

    <quote>
    None of this is easy. Every validation framework I have seen (including my own) is limited to single-field validations (max and min size, required, etc.). Things become even more challenging when your validation logic depends on more than one field.
    <quote>
    Yes, this is true. For more than one field, I think we should use Business Rules Engine (if then else) instead of using user input validation.

    Lofi.
  5. Validation and Business Rules[ Go to top ]

    <quote - Paul Strack>
    I think the best way to configure validations is with external XML files rather than the XDoclet-style Javadoc markup.
    </quote>

    <quote - Lofi Dewanto>
    Why do you think so? I feel that Jakarta commons validator package with those XML is much more complicated to use and to handle. Check this article:
    http://www.onjava.com/pub/a/onjava/2003/07/23/commons.html?page=4
    and look how much code you really need just to validate that simple input. Using Javadoc/XDoclet style is quite simple, IMO.
    </quote>

    I agree that the Jakarta validator framework is harder than it needs to be; that is why I continue to use my own validation framework. However, I think XML is the right place to store even simple validation rules, because validation logic impact more than one layer of the application. For example, you may decide to put in field contraints in your relational database, or client-side validation with Javascript, and having your rules in an XML format makes that easier.

    <quote - Lofi Dewanto>
    IMO, it would be nice if I can describe the validator with the exception its throwing. So, I can catch that Exception in my presentation framework and using Locale to give the best information about each exception. Example:
     
    public interface Person {
      public String getName();
     
      // @validator:mandatory throws InputException
      public void setName(String name);

      // @validator:minmax age > 0 && age < 100
      // throws MinMaxException
      public void setAge(int age);
    }

    -> In my presentation framework for "sequential" error handling:
    // Factory for the Person
    Person myPerson = Person.createPerson("...");
    try {
      myPerson.setName(null);
      myPerson.setAge(200);
    } catch(InputException) {
      ...
    } catch(MinMaxException) {
      ...
    }

    > -> In my presentation framework for "total" error handling:
    // Factory for the Person
    Person myPerson = Person.createPerson("...");
    try {
      myPerson.setName(null);
      myPerson.setAge(200);
    } catch(ApplicationException) {
      // InputException and MinMaxException extend from ApplicationException
      // Use Business Rule Engine for "if then else" Exception handling
      ...
    }

    What do you think about this?
    </quote>

    I usually try to go this route. If possible, I like to make the validation exception message sufficiently accurate that it will make sense to the end user when they read the message. This way, I can just print out ex.getMessage() in the UI and everything is very simple.

    Of the good samples you have above, I think the second client example is better; I prefer to have pretty generic error handling in the UI layer so that I can add additional validation rules in the business layer without worrying about their impact on the UI.

    <quote - Lofi Dewanto>
    For more than one field, I think we should use Business Rules Engine (if then else) instead of using user input validation.
    </quote>

    I agree with you in theory. In practice, putting in a Business Rules Engine is a pretty hefty addition to your application architecture. If your business rules are very mutable and have to be configured by non-developers, I think this is the right decision. If not, it may be overkill, and hand-coding your multi-field validations may be acceptable. I have to admit, though, I have never invested the time in working with a good Business Rules Engine, so I am not speaking from experience here.
  6. Input Validation[ Go to top ]

    <quote>
    However, I think XML is the right place to store even simple validation rules, because validation logic impact more than one layer of the application. For example, you may decide to put in field contraints in your relational database, or client-side validation with Javascript, and having your rules in an XML format makes that easier.
    <quote>
    Hmmm, this is correct. But why should I put my validation rules somewhere else, if putting them on the DTO (or Value Object) or at the EJB Delegate, the best way, anyway?

    Thanx for your good input!
    Lofi.
  7. Input Validation[ Go to top ]

    You put them someplace else because your EJB components may not be the only mechanism ever to manipulate your data. Suppose you give up on your EJBs, or another department wants to build a web service/.NET application. Suppose you want to generate client-side Javascript validation to reduce the load on the server. Suppose you want to update your validation parameters without recompiling your code.

    All of these are easier if your validation rules are in an XML configuration file rather than hard-coded into your DTOs. That is why I prefer this approach.