Implementation of field/property level server side validation

Hi Devs/Hacks,

Some of us have been having an off-list discussion and Lars suggested that we move it to the list for further discussion.

There are two background discussions related to the implementation of a mechanism to validate individual properties of objects.

  1. Is outlined in the blueprint I wrote some time ago here. This is basically asking for a server side mechanism to validate individual properties of objects, somewhat akin to the data validation rules and data integrity rules, but for individual object properties. For instance, maybe we need to prevent things like double and trailing spaces from appearing in things like organisation unit names, or perhaps we want codes to conform to a certain pattern. In principle, regular expressions (regex) can be used to validate these properties. Because of the subtleties of different regex flavor and what they can do, having a server side mechanism is desirable.

  2. Lai has raised some issues with validation of phone numbers. The issue here is that phone numbers need to be entered in international format (+(country code)(number)) in order for them to work properly with international gateways. This is really a more general issue, which we experience in Zambia as well, when numbers need to have a certain amount of digits, but sometimes users do not enter them properly. So, again, we need a mechanism to validate individual properties against a given pattern.

A simple pattern we might like to enforce with numbers might be

‘^+[0-9]$’

to be sure the property starts with a plus and has only digits. In Zambia, we might want to enforce this

‘^+2609[567][0-9]{7}$’

which would mean, the number has to start with +260 (the country code), followed be either a 5,6,7 and then exactly 7 digits afterwards.

In rev 11650, Lai implemented some methods to validate the phone numbers, but was reverted, leading to this mail for discussion among the community.

Both Lars and I feel a more general mechanism would be more appropriate. Summarizing from Lars’s mail,


class ObjectValidation.java

private Class<?> clazz; // Class of object to be validated

private String property; // Property on object to be validated

private String regex; // Regex to validate property value against

private String regexDescription; // Explanation of regex constraint


Then we could have a service interface with method:


interface ObjectValidationService

/**

/* Returns null if all validations passed for the given object. If validation fails, returns the >ObjectValidation which was violated by the given object.

**/

ObjectValidation validate( Object object, String property );

// Use reflection in implementation - collection properties are a problem which requires a clever >solution


Which could later be extended. Of course there are things like JavaEE bean validation but I don’t think >it allows for custom regex (hardcoded ones with @Pattern is supported).

Morten mention in a later mail on our private thread, that Jsr303 also supports this possibly, and examples are in the dhis-web-api-fred.

I personally have needed this type of validation for a long time, to prevent “dirty” data from getting into the system. There was a good step forward with the implementation of the different number types, but we experience continued problems with things like “00” getting into the data value table through mobile imports or CSV imports, which are not subject to the JavaScript regex validation which is the current implementation. Having a server side mechanism with different classes (data entry, import, validation) could utilize to validate properties, could possibly help to filter this out.

Sorry for the long mail, but wanted to take the initiative to flesh out some of the ideas in a bit of detail. Comments welcome.

Regards,

Jason