Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Wiki Markup
{scrollbar}

Forms and Form Components

Main article: Forms and Validation

Contents

Table of Contents
excludeContents|Forms and Form Components
printablefalse

What is the t:formdata hidden field for?

In Tapestry, rendering a form can be a complicated process; inside the body of the Form component are many of field components: TextField, Select, TextArea, and so forth. Each of these must pull data out of your data model and convert it to the string form used inside the client web browser. In addition, JavaScript to support client-side validation must be generated. This can be further complicated by the use of Loop and If components, or made really complicated by the use of Block (to render portions of other pages: this is what the BeanEditForm component does).

...

The 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.

...

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 OverrideFieldFocus mixin forces the email field to be the focus field, regardless.

Wiki Markup
{scrollbar}