Discussions

General J2EE: Validation puzzle

  1. Validation puzzle (4 messages)

    I need some kind of validation for POJO Business Objects. Maybe you can give me some ideas so that I find a good solution?

    I'm looking for a straightforward use of validation. XML validation files are not straightforward in my eyes. I think they are a unnecessary structural interruption between Java files and XML files.

    The Business Objects will not only be used by web clients but by any client type, which includes Swing-Clients. So I do not accept XML files as easily like web application developers.

    Besides that I think that validation has to do a lot directly with the Business Objects. Thats another reason why I don't think its good to insulate validation into a XML file.

    Partly I want to hardcode the validation. I plan to hardcode things like maxValue(shoesize, 20) in the Java code. Other things like enumerations of allowed values I plan to store in the database, for example countryNames and their translations.

    I'm still not sure what to think about the rule based validation techniques I have seen. It seems to me that it shoots sparrows with cannonballs.

    My idea of validation needs bidirectional Business Objects (POJOs). First I would validate field and class internal things like maxValue(shoesize, 20).

    After this I would validate the class on Domain Model scope: shoe.getBrand("Addidas").supportsShoeSize(shoesize) and minSize(brand.getShoes(), 1). Shoe and Brand classes need to be bidirectional for this purpose.

    Wouldn't that be a straightforward use of validation? Why the need for validation rules or even nested validation rules? Why the need to learn a complex validation API or framework before one can start with using validation?

    What about bidirectionality which my idea needs? All POJO Business Object relationships would need to be bidirectional because it enablies validation on Domain Model scope. Is this justifiable (or even recommended)?

    Threaded Messages (4)

  2. simple validation framework[ Go to top ]

    I use something similar on my project as follows which is based on three classes:

    1. Validation - an interface that provides a validate() method which business objects implement (or it can be implemented in a base business object interface - which I do).
    2. ValidaionMessage - a java bean to hold a validation message/warning/error. Consists of the properties: field (name of field), value (bad value), error (name of error), message (optional).
    3. ValidationMessages - an object that holds ValidationMessage objects using a hierarchy. Also provides validation methods, i.e. validateDate, etc.

    The following is an example:

    // example
    public interface Validation {
      ValidationMessages validate();
    }

    public class MyObject implements Validation {
      private String foo;
      private int bar;
      public ValidationMessages validate() {
        ValidationMessages vms = new ValidationMessages(uniqueName);
        vms.checkLength("myobject.foo", foo, 60); // max length 60
        vms.checkRange("myobject.bar", bar, 1, 30) // between 1 and 30
        return vms;
      }
    }

    Points to note:

    1. uniqueName allows nesting of validation messages in a hierarchy.
    2. no if logic in validate method, this is done within ValidationMessages.
    3. Pretty simple to use. Also pretty simple to understand for maintenance.
    4. Allows keys (first params) that cold be used with a resource bundle for formatting.

    Hope this helps!

    Bruce
  3. simple validation framework[ Go to top ]

    Hi Bruce,

    your solution looks good.

    One of my questions was how to implement something like a validation context.

    A business object may be valid only if a field of a related business object is not null for example. How do you validate that? And what if it can't be navigated to the related business object which field needs to be not null? I mean, what if the navigation (getBusinessObjectX()) is only possible in one way and not in the other? Wouldn't that involve to make all related business objects capable of navigating in both directions because to implement validation context?

    If you don't know what I mean, I will try to explain it in a better way.

    My main questing is how to implement validation context.
  4. more validation stuff[ Go to top ]

    Note that I mispoke earlier, I actually use the term Validateable rather than Validation for the interface (no big deal either way).

    I have methods on the ValidationMessages object to validate a child object or children objects as follows:

    checkObject(String relationName, Validatable v);
    checkChildren(String relationName, Collection children);

    For example:

    private List users;
    public ValidationMessages validate() {
      ValidationMessages vms = new ValidationMessages();
      vms.checkChildren("users", users);
      return vms;
    }

    This allows for relationships. As to the validation context, I do use a class called context when I need to share arbitrary data, i.e. I cannot navigate so I need another source to pull from. The context class is pretty much just a slimmed down Map. The issue is mainly that you need to enforce ordering so that you make sure that the data is added to the context before it is needed.

    Could you explain what you mean by validation context and how it differs from what I wrote above. Thanks!

    Bruce
  5. more validation stuff[ Go to top ]

    There seems to be something like Rule Based Validation. That would involve to have a Rule class I think.

    You asked about ValidationContext class. There can be a relationship between Rule and ValidationContext. A ValidationContext could filter rules. That would improve the performance in a GUI if not everything has to be validated every time. Besides this, the ValidationContext could store information whether the context is server or client. The validation context could also depend whether a business object is beeing created, updated or deleted.

    If a customer needs to be registered, then only its name is necessary, but no shipping address. Only when the customer places an order he needs a shipping address. This can be seen as two different validation contexts. In the first context, he doesn't need a shipping address, in the second context he needs it.

    I think the validation context has something to do with use cases (UML). Registration without ordering is a use case and registration with ordering is another use case.

    I'm thinking about how to design a Validation API which is easy to (re)use, easy to learn and which is powerful.

    Maybe you can post your Validation classes here? Its difficult to understand it only with quotations.