Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
 

 



Annotating Object Attributes with Validators 

Model-level "validators" are for automatic validation when there are attempts to save values to the object's fields. Annotations that start with @ followed by an ID (validator name), and that are used on object attributes are validator annotations. See "Creating Complex Validators" below on how to define the validators. The ID value must match the name of a defined validator.

 

.

It is important to note that the validators will execute in the following situations:

  • When a field (object attribute) is set on the frontend and then submitted back to the presenter.
  • Whenever an object is saved, all validators on its attributes will be used to check the validity of the specified.
  • If an object has already been saved and is, as a result, being "tracked" by the ORM, any time an attribute is set, validators will be used to check the validity of the field.

If the first case a message will be displayed to the user of the frontend and submission of the values will be blocked until a valid value is specified.

In the last two cases a validation exception will be throw from the DSL code and a log entry will be created. This exception can be caught in order to handle the exception more elegantly.


Code Block
linenumberstrue
object Person
{
    @FirstnameValidator("validr.msg.fname")
    string fname;
 
    @SurnameValidator("validr.msg.sname")
    string sname;
}
 

 

 




Creating Complex Validators

In a .mez file, under ./model/, use the validator keyword followed by a validator name, followed by a block containing atomic validators:

Code Block
languagejava
titleValidator Examples
linenumberstrue
validator FirstnameValidator {
    notnull(); minlen(2); maxlen(250);
}
validator AgeValidator {
    minval(0);
}
 
validator CTMetroPhoneNumber {
    notnull(); regex("021-[7..9]{7}");
}
 

 

 




Available Atomic Validators

These are the building blocks used for creating complex validators:

 


validator/usagedescription
notnull();Check that the attribute is not null. This validator does not take any arguments.
regex("^[A-Z a-z]*$");

Checks that the value conforms to a regular expression. Allows upper & lower case and spaces.

regex("^[A-Za-z0-9 ]*$");Another regex example. Alphanumeric with spaces.
regex("^27[0-9]*$");Another regex example. Number starting with 27.
regex("\b[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]{2,4}\b");Another regex example. Email.
minval(3.145);

Checks that the value is not less than the supplied minimum value.

maxval(6.18);

Checks that the values is not greater than the supplied maximum value.

minlen(2);

Checks that a string value does not have less characters than the supplied minimum value.

maxlen(255);

Checks that a string value does not have more characters than the supplied maximum value.

 

 

 




Regex Validation in Presenter Units

Whereas the above validators are entered into the model object for automatic validation upon save attempts, any value in a string variable can be compared to a specified regular expression for manual validation with bool b = String:regexMatch(s, r).

Code Block
if (String:regexMatch("27000111abc","^27[0-9]{9,}$") == false) {
    Mez:alertError("alert.invalid.phonenum");
}

 

 

 




Additional Mentions and References

 



Excerpt
hiddentrue

 notnull() etc. | validator | validator annotations