dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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<https://blueprints.launchpad.net/dhis2/+spec/regex-validation>.
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