Using the Validatable interface

You can set the ValidatorFilter() as a global filter so that all your actions implementing the Validatable interface will be validated. Here is how you set this global filter inside your application manager.

Below is an example of how to validate your action using the Validatable interface. Note that you are not using annotation or xml. You are using programmatic configuration to setup the validation of your form fields.

To each form field is applied a set of validation rules. For example, for the field "age" we are applying two rules:

RequiredRule: enforces that a field is present, in other words, not blank or null

IntegerRule: enforces that a field is an Integer between a min and a max value

Mentawai validation rules are as flexible as Java code because they are Java code, not XML or Annotation. If you check the javadoc of the IntegerRule class you will find out that it has three different constructors:

IntegerRule(): meaning any integer will be accepted, even negative integers

IntegerRule(int min): meaning any integer >= min will be accepted

IntegerRule(int min, int max): meaning any integer >= min and <= max will be accepted

Mentawai comes with many read-to-use rules in the package org.mentawai.rule like StringRule, NumberRule, EmailRule, FileRule, etc. Plus it comes with a very handy rule called RegexRule which allows you to validate any field based on a regular expression. You will not be surprised to find out that many other Mentawai rules (like the EmailRule) inherit from RegexRule to do its job. As we will see later in this chapter, it is very, very easy to create your own rules for validation as well in case the provided ones do not suit your needs.

If a validation rule fails, a error message associated with it is displayed to the user. Because these messages are usually internationalized (translated into many languages) and more strongly because you don't want to mix content with source code, they should reside in a text file we call i18n file. (Soon you will see how to bypass this good practice and place your error messages together with your code if you prefer to)

The default location for your validation error messages are /validation/actionamehere_localehere.i18n. However if you prefer to keep all your messages in a single file (that we call master) you can invoke the following method inside your application manager:

If you do this, all your messages, not just for validation but all internationalized messages in your application will be stored in the file /i18n/master_localehere.i18n.

So for example if your are NOT using the master file, your action is MyAction (like our example above) and you have two languages pt and en, you would have the following files: /validation/MyAction_pt.i18n and /validation/MyAction_en.i18n.

But if you are using the master file, then all your messages from all your actions would be stored in the files: /i18n/master_pt.i18n and /i18n/master_en.i18n.

Some people will prefer to store all text messages in a single file what makes things easier when it comes the time to translate everything to a new language. Other people will prefer to have a separate file for each action. It is up to you what approach to take.

An example of the validation messages for the action above is listed below:

Note how we are using the tokens %min% and %max% to place some validation information inside our error messages. You should already be familiar with the i18n file syntax because it is the same of the Java Properties class.

Now to display these messages inside a JSP page, all you have to do is make use of some very useful mentawai tags. See our example below:

Note that this tags are conditional tags, in other words, nothing inside the tag will be shown if there is no error for the field. If you want to display all field errors in the top of your page instead of near each field in your form, you can use another menta tag, the <mtw:outFieldErrors> tag.

To conclude, an important tip that we will see later in the book: Use the Mentawai HTML form tags <mtw:input>, <mtw:select>, <mtw:checkboxes>, etc. so you don't have to worry about re-displaying the values that the user typed in case of validation error. We know you don't want to place a bunch of scriptlets in your JSPs to do this.