[CONF] Apache Tapestry Forms and Validation
Forms and Validation
Page edited by Bob Harner
Comment:
Added note about Tap 5.4 not redirecting after form validation failures
Changes (1)
...
h1. Storing Data Between Requests
{float:right|background="" {since:5.4} Note: 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 persistent field to store the tracker. {since} {float}
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|Persistent Page Data] between requests, or all the validation information will be lost (the default ValidationTracker provided by the Form is persistent).
...
Full Content
Related Articles
Page:
Forms and Validation
Page:
Forms and Form Components FAQ
Page:
Bean 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.
Tapestry excels at creating forms and validating input. Input validation is declarative, meaning you simply tell Tapestry what validations to apply to a given field, and it takes care of it on the server and (once implemented) on the client as well.
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.
The Form component generates a number of component events that you may provide event handler methods for.
When rendering, the Form component emits two notifications: first, "prepareForRender", then "prepare". These allow the Form's container to setup any fields or properties that will be referenced in the form. For example, this is a good place to create a temporary entity object to be rendered, or to load an entity from a database to be edited.
When user submits the form on the client, a series of steps occur on the server.
First, the Form emits a "prepareForSubmit" notification, then a "prepare" notification. These allow the container to ensure that objects are set up and ready to receive information from the form submission.
Next, all the fields inside the form are activated to pull values out of the incoming request, validate them and (if valid) store the changes.
For Tapestry 4 Users: Tapestry 5 does not use the fragile "form rewind" approach from Tapestry 4. Instead, a hidden field generated during the render stores the information needed to process the form submission.
After the fields have done their processing, the Form emits a "validateForm" event. This is a chance to perform cross-form validation that can't be described declaratively.
Next, the Form determines if there have been any validation errors. If there have been, then the submission is considered a failure, and a "failure" event is emitted. If there have been no validation errors, then a "success" event is emitted.
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 a 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.
The Form includes methods isValid() and getHasErrors(), which are used to see if the Form's validation tracker contains any errors.
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
[CONF] Apache Tapestry Built-in Mixins
Built-in Mixins Page edited by Bob Harner Comment: Added OverrideFieldFocus mixin reference; fixed typo. Changes (3) ... | [Autocomplete|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/Autocomplete.html] | modifies a text field to provide for auto-completion of text using values retrieved from the server as the user types. [See instructions|Ajax and Zones#autocomplete]. | | [DiscardBody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/DiscardBody.html] | discards a components body. Returns false from the BeforeRenderBody phase, which prevents the rendering of the body. | | [FormFieldFocus|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/FormFieldFocus.html] |A mixin that instruments the outer Form on which component the focus should be activated. Replaced by OverrideFieldFocus starting in Tapestry 5.4. | | [NotEmpty|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/NotEmpty.html] | attaches to an element that renders an element. At the end of the render, if the element is empty, then a non-breaking space (nbsp\;) is injected into the element. | | [OverrideFieldFocus|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/OverrideFieldFocus.html] | A mixin that, when attached to a form field, causes that field to gain focus. Starting in Tapestry 5.4, this supersedes FormFieldFocus. | | [RenderClientId|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/RenderClientId.html] | forces a client element to render its client id by ensuring that getClientId is called. | | [RenderDisabled|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/RenderDisabled.html] | renders an disabled attribute if the containing component is disabled | | [RenderInformals|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/RenderInformals.html] | renders out all informal parameters, at the end of the BeginRender phase. This mixin can be used with components that render a single tag inside the BeginRender phase. | | [RenderNotification|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/mixins/RenderNotification.html] | triggers event notifications to identify when it enters the BeginRender and AfterRender render phases | ... Full Content Tapestry includes the following mixins out-of-the-box. Autocomplete modifies a text field to provide for auto-completion of text using values retrieved from the server as the user types. See instructions. DiscardBody discards a component's body. Returns false from the BeforeRenderBody phase, which prevents the rendering of the body. FormFieldFocus A mixin that instruments the outer Form on which component the focus should be activated. Replaced by OverrideFieldFocus starting in Tapestry 5.4. NotEmpty attaches to an element that renders an element. At the end of the render, if the element is empty, then a non-breaking space (nbsp;) is injected into the element. OverrideFieldFocus A mixin that, when attached to a form field, causes that field to gain focus. Starting in Tapestry 5.4, this supersedes FormFieldFocus. RenderClientId forces a client element to render its client id by ensuring that "getClientId" is called. RenderDisabled renders an "disabled" attribute if the containing component is disabled RenderInformals renders out all informal parameters, at the end of the BeginRender phase. This mixin can be used with components that render a single tag inside the BeginRender phase. RenderNotification triggers event notifications to identify when it enters the BeginRender and AfterRender render phases TriggerFragment a mixin that can be applied to a Checkbox or Radio component that will link the input field and a FormFragment, making the field control the client-side visibility of the FormFragment ZoneRefresh This mixin periodically refreshs a Zone by triggering an event on the server using ajax requests. Change Notification Preferences View Online | View Changes
