Re: [Figleaf-developer] Validation mechanism

[Greg S. <ste...@on...>]

sam...@ma... wrote:

>I've been kicking around some ideas for the validation mechanism.
>
>My plan is for a ValidationRule object, which is associated with a
>ProperyDescriptor. A CompositeValidationRule will allow for multiple
>ValidationRules to apply to a single property. The interface defines one method:
>
>boolean validate(Object value, ValidationCallback callback);
>
>If it validates, true is returned. If it doesn't, false is returned. In either
>case a callbackmethod will be called - ValidationCallback looks like this:
>
>void valid(PropertyDescriptor property, Object validValue);
>void invalid(PropertyDescriptor property, Object invalidValue, String errorMessage);
>
>The method names suck, but I think the idea is sound. The GUI can then register
>a callback to automatically seed the UI with validation messages.
>  
>

First let me make sure I understand correctly:

Say the GUI has a new value just entered into a text field for a 
property. It will call validate(newValue, mycallback) on the 
ValidationRule returned by the PropertyDescriptor. If true is returned, 
it will proceed to call the PropertyDescriptor's write method. If false, 
it'll do nothing, but the invalid() callback should display an error 
message (or some other action).

>We could take this a step further - when calling the write methods,
>automatically invoke the validation firing callback methods as required.
>
I think this is actually a nicer approach. Then the client code doesn't 
have to worry about calling validate(). It just will use the write 
method, and if the data is valid it is accepted, if not it is rejected. 
Then the listener will register itself with the PropertyDescriptor 
before doing anything such as:

propertyDescriptor.addValidationListener(
    new ValidationListener(){
      public void valid(PropertyDescriptor property, Object validValue){
          //do something
      }

      public void invalid(PropertyDescriptor property, Object 
invalidValue, String errorMessage){
         //do something
          //display error message
      }
 }
);

Also this allows multiple validation listeners to be registered for any 
given property descriptor. That would be useful if there should be a 
generic listener set on all properties for logging or something else.

Finally, I would suggest a global validation check which would have to 
be explicitly called on the object. This would be to validate the object 
before final saving, to handle validation checks that can only be 
performed on a combination of properties. Then the gui/client code would 
look something like:

public void saveObject(Informative inf){
   String[] ErrorMessages=inf.validate();
    if(ErrorMessages != null){
         //display errors
    }else{
        //no errors
        objectManager.save(inf);
    }
}


>
>Ideas for ValidationRules:
>
>RegexpValidationRule <- Passes if string value of Object matches the whole regexp
>CompositeValidationRule <- Wraps several rules
>DateValidationRule <- Validates date regions
>NumberValidationRule <- Ditto for dates
>  
>
For a composite rule, should we only allow logical AND's of rules? That 
is they must all pass for validation to succeed. Or should we also 
support logical combinations of rules? That'll make the API more complex 
but also more powerful. We can always start with AND only, and then add 
on to it later.

>We'll also want to add an AbstractValidationRule to make it easy for users to
>add their own - it'll simply add the callback support.
>
>This is all fairly easy to write and test so shouldn't take me too long to write
>- I can probably check in the interfaces for you to hook into before the weekend
>(and probably at least one concrete implementation).
>
>The only question to answer now, is where do we get the rules from? The obvious
>place is a PropertyDescriptor - lets add this method:
>
>ValidationRule getValidationRule();
>
>sam
>http://www.magpiebrain.com/
>  
>
Yes I think that is the logical place to get it from.

And the "global" check could be placed in the Validatable interface as 
it was at some point in the past.

Greg