...
Please make sure you have read the Tag Syntax document and understand how tag attribute syntax works.
Within the form tags, there are two classes of tags: the form tag itself, and all other tags, which make up the individual form elements. This is important as the The behavior of the form tag itself is different than that of the elements enclosed within it. Before we go provide a reference for all the form tags, including the form tag itself, we must outline some general characteristics first.
...
.
Form Tag Themes
As previously noted explained in Themes and Templates, the HTML Tags (which includes Form Tags) are all driven by templates. Templates are grouped together to form create themes. By default, WebWork provides three themes:
...
The framework bundles three themes in the distribution.
...
simple | Sometimes too simple |
---|---|
xhtml | Extends simple |
(default) |
ajax |
---|
...
Extends xhtml |
The predefined themes can be used "as is" or customized.
...
The xhtml theme renders out a two-column table. If
...
a different layout is needed,
...
do not write your own HTML
...
. Create a new theme or utilize the simple theme.
Simple theme caveats
The downside of using the simple theme is that it doesn't support as many of the attributes that the other themes do. For example, the label
attribute does nothing in the simple theme. Similarly, the functionality offered by the simple theme is much less than that of the xhtml and ajax themes: the automatic display of error messages is not supported.
Common Attributes
All the form tags extend the UIBean class. This base class generally provides a set of common attributes, that can be grouped in to three classescategories: templated-related
, javascript-related, and general attributes. We won't document what these attributes do here as that is taken care of in each individual The individual attributes are documented on each tag's reference . However, it is a good idea to familiarize yourself with the structure of the UI tags and what attributes are available for all tags.page.
In addition to these the common attributes, a special attribute exists for all form element tags: form
(ie: ${parameters.form}). This The form
property represents the parameters attributes used to render the form tag and allows you to provide interaction between your form elements and the form itself. For example, in a template you could access , such as the form's id. In a template, the form's ID can be found by calling ${parameters.form.id}.
Template-Related Attributes
...
Javascript-Related Attributes
...
...
Tooltip Related Attributes
...
...
General Attributes
...
...
Some tag attributes may not be utilized by all, or any, of the templates. For example, the form tag
...
supports the tabindex
attribute, but none of the themes render
...
the tabindex
.
Value/Name Relationship
In many of the tags , (except for the form tag, ) there is a unique relationship between the name
and value
attributes. The name
attribute is what the form element gets named and eventually submitted as. This effectively is the expression to which you wish to bind the incoming value toprovides the name for the tag, which in turn is used as the control attribute when the form is submitted. The value submitted is bound to the name
. In most cases, it is the name
maps to a simple JavaBean property, such as "firstNamepostalCode". This would eventually call setFirstName().
Similarly, you often wish to also display in your form elements existing data from the same JavaBean property. This time, the attribute value is used. A value of "%{firstName}" would call getFirstName() and display it in your form, allowing users to edit the value and re-submit it.
You could use the following code, and it would work just fine:
...
<@ww.form action="updatePerson">
<@ww.textfield label="First name" name="firstName" value="%{firstName}"/>
...
</@ww.form>
However, because the relationship between name and value is so often predictable, we automatically do this for you, allowing you to do:
...
On a submit, the value would be set to the property by calling the setPostalCode
mutator.
Likewise, a form control could be populated by calling a JavaBean accessor, like getPostalCode
. In the expression language, we can refer to the JavaBean property by name. An expression like "%{postalCode}" would in turn call getPostalCode
.
...
However, since the tags imply a relationship between the name
and value
, the value
attribute is optional. If a value
is not specified, by default, the JavaBean accessor is used instead.
...
While most attributes are exposed to the underlying templates as the same key as the attribute (ie: ${parameters.label}), the value
attribute is not. Instead, it can be accessed via the "nameValue
" key (ie: ${parameters.nameValue}) to indicate that it . The nameValue
key indicates that the value may have been generated from the name
attribute rather than explicitly defined in the value
attribute.
ID Name Assignment
All form tags automatically assign an ID for you. You are free to override this ID if you wish. The ID assignment works as follows:
- For forms, the ID is the assumed to the action name. In the previous example, the ID would be "updatePerson".
Wiki Markup For form elements, the ID is assumed to be \[form's ID\]_\[element name\]
Required Attribute
to the control, but the ID can be overridden if needed.
Forms | The default ID is the action name. For example, "updateAddress". |
---|---|
Controls | The default ID is the form's name concatenated with the tag name. For example, "updateAddress_postalCode". |
Form labelposition propagation
When labelposition
attribute was defined for <s:form>
tag it will be propagated to all form elements, but if form element defines its own labelposition
it will take precedence over <s:form>
's attribute. Since 2.3.17.
Required Attribute
The required
attribute on many The "required" attribute on many WebWork UI tags defaults to true only if you have client-side validation enabled, and there is a validator is associated with that particular field.
Tooltip
...
...
Form Tag Reference
Note |
---|
It's very important to note that all tags that insert something into the valuestack (like i18n or bean tags) will remove those objects from the stack on its end tag. This means that if you instantiate a bean with the bean tag (<ww:bean name="'br.univap.fcc.sgpw.util.FormattersHelper'">) that bean will be avaliable on the valuestack only until the </ww:bean> tag. |
...