Forms and Form Components
Main article: Forms and Validation
What is the
t:formdata hidden field for?
Along the way, the Form is generating unique form control names for each field component, as it renders.
When the client-side Form is submitted, an event is triggered on the server-side Form component. It now needs to locate each component, in turn, inform the component of its control name, and allow the component to read the corresponding query parameter. The component then converts the client-side string back into a server-side value and performs validations before updating the data model.
t:formdata comes in. While components are rendering, they are using the FormSupport environmental object to record callbacks:
ComponentAction objects are the callbacks.
t:formdata is simply an object stream of these callbacks, compressed and encoded in Base64. When using Ajax, you may see multiple
t:formdata hidden fields (they are processed one after another).
How do I change the label for a field on the fly?
Tapestry tries to be smart about generating the label string for a field. It has some smart default logic, first checking for the component-id
-label in the container's message catalog, then ultimately converting the component's id into a user-presentable label.
You can override the label in two ways:
First, you can supply a body to the
Here, the component class must provide a
usernameLabel property. That property becomes the text of the label. An implementation of the property might look something like:
However, if there are any validations on the field, the error message will include the default label (as discussed above).
To uniformly update the label both on the page, and in any validation messages, bind the TextField's
The "prop:" prefix identifies that "usernameLabel" is to be interpreted as a property expression (normally, the binding for the
label parameter is interpreted as a string literal). The Label component gets the text it displays from the TextField component, and the TextField component uses the same text when generating server-side and client-side validation messages.
Tapestry focuses on the wrong field in my form, how do I fix that?
Tapestry normally figures out the correct field in your form to initially receive focus; this is based on assigning a FieldFocusPriority to each field as it renders, which works out to the following logic:
- The first field which has an error
- Or, the first field which is required
- Or, the first field
Here's an example
The OverrideFieldFocus mixin forces the email field to be the focus field, regardless.