respect basic validators in app (translated from wq.db models)

[tomaszn]

If a Django model field is defined with validators, they should be propagated down through the configuration and used for new/edit screens on the client.
In general it is impossible to use the same validation code on the client (Python code run on the server vs JavaScript in the browser). However:

• basic validators could be translated (MaxValueValidator, MinValueValidator, MaxLengthValidator, MinLengthValidator, DecimalValidator);

• stubs for the rest could be generated and a warning issued; if a validator is used by different models, it should also be reused on the client side.

[sheppard]

Yes, it would be good to automate more of these. Most of the basic validators could likely be translated directly into HTML5 attributes on the <input>. We would just need to think a little about how to represent these in the JSON config - and also whether we can map this to the output of xlsconv. Ideally implementers could start with an XLSForm containing constraints, and have the templates and Django models both generated with the appropriate validators already in place. The one challenge might be that the XLSForm constraint syntax is written more like a query language so it might not have a one-to-one mapping to Django's concepts.

For more complex validators I do like the idea of implementing stubs. My one question would be if you strictly need instant offline validation, or if you are okay waiting for a sync. wq.app and the default templates are set up so that if the server validation fails, you can re-open the failed record from the outbox to see the server's error message(s) for each field and for the record as a whole.

[tomaszn]

Instant offline validation would be useful, because after returning from the field one may not remember the proper answer. Example: a required field "tail length" was left empty, when it is essential for scientists.