Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
Using the bean editor, we can easily create a simple form for collecting information
from the user. In this example, we'll collect a little bit of data about a User:
The bean to edit will be a property of the containing page.
The @NonVisual annotation prevents the id from being displayed.
Create New User
]]>
Nominally, we should have to bind the object parameter of the BeanEditForm component. However, as
a convenience, Tapestry has defaulted the object parameter
based on the component id. This works because the CreateUser class
includes a property named "user", which matches the BeanEditForm component's id.
When the object to be edited is not a direct property of the page,
it will be necessary to bind the object parameter explicitly. For example,
object="registration.address"
to create or edit the address
property of the page's registration property. Component ids may not contain periods,
so there's no way to specify this without the object parameter. A best practice is to still
explicitly set the component's id, thus:
]]>
We are using the page's message catalog to supply a messages. Externalizing such messages
make them easier to work with, especially for an application that may be localized.
The
create-user
key is explicitly referenced (submitlabel="message:create-user").
This becomes the label on the submit button for the generated form.
The two label keys will be picked up and used as the labels for the corresponding properties
(in both the rendered <label> elements, and in any error messages).
In many cases, common entries can be moved up to an application-wide message catalog. In that case,
the page's own message catalog becomes a local override.
Notice that we don't instantiate the User object ourselves; instead we let the BeanEditForm
component
do that for us. It's capable of doing so because the User class has a default public no arguments
constructor.
The onSuccess() method is invoked when the form is submitted with no validation errors (although
client validation is enabled by default, server-side validation is
always
enforced).
The UserDAO service is used to add the new user.
Returning a class from an event handler method (UserAdmin.class) will
activate the indicated page as the response page. As always, a redirect to to the response page is
sent to the client.
By placing some annotations on the properties of the User class, we can enable client-side
validations. In addition, we can override the default editor components for a property
to add some additional instructions.
The new @Validate annotations added to the first name and last name properties indicates that a
non-blank
value must be provided. For the age property we are setting minimum and maximum values as well.
Validation for each field occurs when the form is submitted, and when the user tabs out of a field.
If you submit
immediately, Tapestry will display popup bubbles for each field identifying the error:
In addition, fields with errors are marked with a red X, the font for the first turns red, and the
label
for the field turns red. We're providing a lot of feedback to the user.
After a moment, all the bubbles except for the current field fade. Bubbles fade in and out as you
tab from field to field.
We can customize how individual properties are editted. Here we'll
add a small reminder next to the age property:
Users must be between 18 and 99.
]]>
The
]]>
element
is an
override
for the property. The name is
matched against a property of the bean. We need to provide a
Label
component, and an appropriate
editor component.
You can re-order the properties using the reorder parameter:
]]>
You can accomplish the same thing by changing the order of the
getter methods in the bean class. The default order for properties is not alphabetical,
it is the order of the getter methods.
You can also remove properties with the exclude parameter, which is equivalent to the
@NonVisual annotation.
