{float:right|background=#eee}
{contentbylabel:title=Related Articles|showLabels=false|showSpace=false|space=TAPESTRY|labels=validation}
{float}

Form Input and Validation

The life's blood of any application is form input; this is the most effective way to gather significant information from the user. Whether it's a search form, a login screen or a multi-page registration wizard, forms are how the user really expresses themselves to the application.

...

Finally, Tapestry is able to not only present the errors back to the user, but to decorate the fields and the labels for the fields, marking them as containing errors (primarily, using CSS effects).

Form component

The core of Tapestry's form support is the Form component. The Form component encloses (wraps around) all the other field components such as TextField, TextArea, Checkbox, etc.

...

Last, the Form emits a "submit" event (for logic that doesn't care about success or failure).

Tracking Validation Errors

Associated with the Form is an ValidationTracker that tracks all the provided user input and validation errors for every field in the form. The tracker can be provided to the Form via the Form's tracker parameter, but this is rarely necessary.

...

In your own logic, it is possible to record your own errors. Form includes two different versions of method recordError(), one of which specifies a Field (an interface implemented by all form element components), and one of which is for "global" errors, unassociated with any particular field.

Storing Data Between Requests

As with other action requests, the result of a form submission is to send a redirect to the client which re-renders the page. The ValidationTracker must be stored persistently between requests, or all the validation information will be lost (the default ValidationTracker provided by the Form is persistent).

...

Finally, notice how business logic fits into validation. The UserAuthenticator service is responsible for ensuring that the userName and (plaintext) password are valid. When it returns false, we ask the Form component to record an error. We provide the PasswordField instance as the first parameter; this ensures that the password field, and its label, are decorated when the Form is re-rendered, to present the errors to the user.

Configuring Fields and Labels

The template for a page contains a minimal amount of Tapestry instrumentation:

...

The validate parameter was placed within the Tapestry namespace using the t: prefix. This is not strictly necessary, as the template is well formed either way. However, putting the Tapestry specific values into the Tapestry namespace ensures that the template will itself be valid.

Errors and Decorations

Note: This section has not been updated to reflect the introduction of client-side input validation.

...

This is nice and seamless; the same look and feel and behavior for both the built-in validators, and for errors generated based on application logic.

Centralizing Validation with @Validate

The @Validate annotation can take the place of the validate parameter of TextField, PasswordField, TextArea and other components. When the validate parameter is not bound, the component will check for the @Validate annotation and use its value as the validation definition.

The annotation may be placed on the getter or setter method, or on the field itself.

Customizing Validation Messages

Each validator (such as "required" or "minlength") has a default message used (on the client side and the server side) when the constraint is violated; that is, when the user input is not valid.

...

If that does not match a message, then the built-in default validation message is used.

Customizing Validation Messages / BeanEditForm

The BeanEditForm component also supports validation message customizing. The search is the similar; the formId is the component id of the BeanEditForm component (not the Form component it contains). The fieldId is the property name.

Configuring Validator Contraints in the Message Catalog

It is possible to omit the validation constraint from the validator parameter (or @Validator annotation), in which case it is expected to be stored in the message catalog.

...

This technique also works with the BeanEditForm; as with validation messages, the formId is the BeanEditForm component's id, and the fieldId is the name of the property being editted.

Available Validators

Currently Tapestry provides the following built-in validators:

Overriding the Translator with Events

The TextField, PasswordField and TextArea components all have a translate parameter, a FieldTranslator object that is used to convert values on the server side to strings on the client side.

...