Forms are the traditional way for most web applications to gather significant information from the user. Whether it's a search form, a login screen or a multi-page registration wizard, Tapestry uses standard HTML forms, with HTTP POST actions by default. In addition, AJAX-based form submission is supported using Zones.
Div | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
...
The Form component emits a number of component events. You'll want to provide event handler methods for some of these.
...
Handling Events
Main Article: Forms and Validation Component Events
You handle events by providing methods in your page or component class, either following the onEventFromComponent() naming convention or using the OnEvent annotation. For example:
...
Wiki Markup |
---|
{float:right|width=40%} {info:title=New in Tapestry 5.4} Starting in Tapestry 5.4, the default behavior for server-side validation failures is to re-render the page within the same request (rather than emitting a redirect). This removes the need to use a session-persistent field to store the validation tracker when validation failures occur. {info} {float} |
...
HTML5 Client-side Validation
When the tapestry.enable-html5-support
configuration symbol is set to true (it is false by default), the Tapestry's built-in validators will automatically enable the HTML5-specific "type" and validation attributes to the rendered HTML of Tapestry's form components, triggering the HTML5 client-side validation behavior built into most modern browsers. For example, if you use the "email" and "required" validators, like this:
Code Block | ||
---|---|---|
| ||
<t:textfield validate="email,required" .../> |
then the output HTML will look like this:
Code Block | ||
---|---|---|
| ||
<input type="email" required ...> |
...
The message can be customized by adding an entry to the page's message catalog (or the containing component's message catalog). As with any localized property, this can also go into the application's message catalog.
...
Customizing Validation Messages for BeanEditForm
The BeanEditForm component also supports validation message customizing. The search for messages is similar; the formId is the component id of the BeanEditForm component (not the Form component it contains). The fieldId is the property name.
...
Lists of validators can be combined into validation macros. This mechanism is convenient for ensuring consistent validation rules across an application. To create a validation macro, just contribute to the ValidatorMacro Service in your module class (normally AppModule.java), by adding a new entry to the configuration object, as shown below. The first parameter is the name of your macro, the second is a comma-separated list of validators:
Code Block | ||||
---|---|---|---|---|
| ||||
@Contribute(ValidatorMacro.class) public static void combinePasswordValidators(MappedConfiguration<String, String> configuration) { configuration.add("passwordpasswordValidator","required,minlength=5,maxlength=15,"); } |
Then, you can use this new macro in component templates and classes:
Code Block | ||
---|---|---|
| ||
<input t:type="textField" t:id="password" t:validate="passwordpasswordValidator" /> |
Code Block | ||
---|---|---|
| ||
@Validate("password") private String password; |
...