Validation of local models

[cjblomqvist]

In order for validation to be useful (as pointed out by Pavel) it should be tied to the UI in some way. My thoughts are that it is quite common you'd want to validate some data before you save it to DB. Most typical create/update tasks in regular CRUD apps fall under this scenario. Unless you don't care about validating your data, this needs to be done before (or some complicated mechanism for reverting changes needs to exists) submitting it to the server. However (as also pointed out by racer-schema/Pavel, as well as Nate), it is not feasible because sometimes you don't actually know the outcome of the change beforehand (unless you create a complete, i.e. deep, copy of all data and apply the change, but that is very expensive).

Nate suggested to do custom code, but it seems that it would be nice to either be able to re-use schemas specified in DB/model -models (e.g. what has been possible since 0.1.0). Also, it would be nice to have a plugin to declaratively define validation for a set of fields, including default values, to keep code more DRY. Thus, it would be nice to be able to specify a schema for a specific local model and be able to validate/apply default values to this model.

Questions still to answer remain though. First off, do you want to validate all the time? In many scenarios, you'd want to start validation at a certain point and not from the start. For example, if you enter a registration form you don't want to have validation from the first key stroke (it would just invalidate the vast majority of fields straight away), but rather when you actually hit the submit button. However, after that you'd want to get the errors for each field, and then reactively (i.e. on each change to the data) validate the data to update the errors in the GUI accordingly. Further, this would probably differ from different scenarios. Thus, there would be a need to:

• Start validation
• Stop validation
• Do a one-time validation

(which can probably be methods automatically added to the model at hand)

Further, at some point one would want the default values to be applied. It seems the first time would be appropriate to apply default values. However, if the validation fails one would probably not want the fields to be filled in automatically with the default values for those fields that were not filled in (or?) Further, it might be wanted to actually have the default values applied before any validation has happened at all, to be able to rely on that for certain other dependent operations. The question is then, when is the data/object first really created? Sometimes it might only be connected to the GUI through paths but never actually explicitly created. One solution would be to apply it on get's, but that would be complicated when dealing with sub-paths (and in particular, complicated sub-sub-sub-paths).

Thus, it seems there would be a need to be able to "manually" trigger applying defaults.

Sensible defaults seems like needed for this as well. Possibly overridable by an options parameter?

[cjblomqvist]

Even further, to enable using the same schema (or a part of another DB-schema), this needs to be easily available somehow on the original schema so it can easily be copied (referenced) to the local model's schema.

[cjblomqvist]

Local validation is now dealt with in derby-validator ( https://github.com/BBWeb/derby-validator ). That lib can easily be modified to accept (or even sniff up) rules from a model (i.e. declaratively defined schemas to a specific collection). Server-side (i.e. real validation) and model layer validation still remains though.

[cjblomqvist]

And with local validation in my previous comment I mean when doing a copy into the view model/scoped component model and before applying that data to the model. There's still no connection to declaratively define a schema (it doesn't currently work) and thus derby-validator does not yet automatically sniff up the schema to validate against. However, that might be enough to cover all validation except for the "proper" server-side validation inside of share (which should only validate that the user is not side-stepping the code).