Minor docs / understanding validator issue

[Blama]

Hi Isomorphic,

please see these docs:

A validator describes a check that should be performed on a value the user is trying to save.

This class is not meant to be created and used, it is actually documentation of settings allowed in a DataSource descriptor (.ds.xml file), for use with Smart GWT Pro Edition and above. See com.smartgwt.client.docs.serverds for how to use this documentation.



Validators are specified for DataSource fields via the DataSourceField.validators property. Validators that need not be run on the server can also be specified for a specific FormItem or ListGridField.

Smart GWT supports a powerful library of ValidatorTypes which have identical behavior on both the client and the server.

Beyond this, custom validators can be defined on the client and custom validation logic added on the server. Note that the regexp and mask validator types are very flexible and can be used to perform virtually any kind of formatting check that doesn't involve some large external dataset.

Custom validators can be reused on the client by adding them to the global validator list, via the addValidator() method.

It seems to me that validators are executed in the order of definition, which is a good and reasonable thing, especially considering stopIfFalse, which would not make sense with a random order.
Could you confirm and include the information that the validators are executed in order in the docs?

Best regards
Blama

[Isomorphic]

Hi Blama
Yes, validators defined on a DataSource field are executed in the order in which they are defined, as you'd expect. To fill in a couple of edge cases for completeness:
- Explicitly defined validators on the dataSource field are run in the order in which they are defined on the client and on the server. Obviously any server-only validators are skipped on the client, and any client-only validators are skipped on the server.
- Implicit type validators (an "isInteger" validator being applied automatically to all fields of type "Integer", for example) are run before any validators applied explicitly at the field level
- If a component has explicitly applied validators in addition to those picked up from the DataSourceField definition, the component-level validators will execute first. (This of course does not apply to server side validation).

[Blama]

Hi Isomorphic,

thanks. Can you also add this in the docs?

Thank you & Best regards
Blama

[Blama]

Hi Isomorphic,

actually this feature should also be mentioned in the header of docs.serverds.Validator.
I stumbled upon it only rencently.

Also MASK and REGEXP validator types should mention this, especially, as MASK already mentions a clientside-only way to to this (SmartGWT sample / SmartClient Sample). Server-transform would be much more powerful here.

Best regards
Blama

[Blama]

Hi Isomorphic,

stumbled on this one again searching the forums. All the last posts might help in the docs.

Best regards
Blama

[Blama]

Hi Isomorphic,

could you add the general "validators are executed in the order" from here

Yes, validators defined on a DataSource field are executed in the order in which they are defined, as you'd expect. To fill in a couple of edge cases for completeness:
- Explicitly defined validators on the dataSource field are run in the order in which they are defined on the client and on the server. Obviously any server-only validators are skipped on the client, and any client-only validators are skipped on the server.
- Implicit type validators (an "isInteger" validator being applied automatically to all fields of type "Integer", for example) are run before any validators applied explicitly at the field level
- If a component has explicitly applied validators in addition to those picked up from the DataSourceField definition, the component-level validators will execute first. (This of course does not apply to server side validation).

in either the header of docs.serverds.Validator or stopIfFalse (preferred here) docs?

I wanted to use stopIfFalse for the 1st time now and stumbled upon this again.

Best regards
Blama