Services and forms

Processing of requests for Form components is a little more complicated than for ordinary ActionLink components. This is because a Form will wrap a number of form-related components, such as TextField, Checkbox, PropertySelection and others.

In order to accept the results posted in the HTML form, each of these components must be given a chance to respond to the request. A component responds to the request by extracting a request parameter from the HttpServletRequest, interpreting it, and assigning a value through a parameter.

As with an ActionLink component, a full rewind must be done, to account for conditional portions of the page and any Foreach components.

[Note]Note

Starting with Tapestry release 1.0.2, Forms may now use the direct service instead of the action service; this is configurable. Using the direct service is the default behavior unless specified. A rewind still occurs, it simply starts directly with the Form component, rather than having to "work down" to it. This can be a performance gain if a page contains many forms.

The Form component doesn't terminate the rewind cycle until after all of its wrapped components have had a chance to render. It then notifies its own listener.

The basic components, TextArea and TextField, are quite simple. They simply move text between the application, the HTML and the submitted request.

Individual Checkbox components are also simple: they set a boolean property. A RadioGroup and some Radio components allow a property to be set to a value (dependent on which radio button is selected by the user). The PropertySelection component is designed to more efficiently handle this and can produce HTML for either a popup list or a collection of radio buttons.

Tapestry also includes the more involved component, ValidField, which is similar to the simple TextField component, but provide greater validation and checking of input, and provides the ability to visually mark fields that are required or in error.

Regardless of which service the Form uses, it encodes the query parameters (which identify the service and context) as hidden field elements, rather than encoding them into the URL. This is necessary because some servlet containers ignore URL query parameters when using the HTTP POST request; therefore, it is necessary that all query parameters (including the ones related to the engine service), be part of the form posting ... and that means the use of hidden fields in the form.