Beginning Apache Struts - From Novice To Professional (2006)

Attributes

All common attribute sets (evt-attrs, acc-attrs, ren-attrs, struts-attrs, init-attr, and the new err-attrs) are accepted, and have their usual meanings.

Besides these, there are a few attributes specific to both text and password:

•size: The length of the displayed field. If omitted, the decision is left to the browser.

•readonly: If true, the text field may not be edited.

•maxlength: Maximum number of characters to accept. The default is to allow an unlimited number of characters.

The password tag has an additional boolean attribute called redisplay, which defaults to true. This causes the previously keyed password (when a form is redisplayed because of validation errors) to appear as asterisks. Unfortunately, the actual password is also embedded in the HTML for that page. You should set redisplay=false to prevent passwords being harvested from cached pages.

Examples

The code

<html:text property="email" />

specifies a text input field for the property called email on the current form bean.

<html:password property="pwd" />

specifies a password field.

Equivalents

JSF’s <h:inputText> is an equivalent for <html:text>, but you need to enclose it within the Struts-Faces <s:form> tag so that the associated form bean is populated with the submitted value:

<s:form ...

<!-- equivalent to html:text -->

<h:inputText id="email" binding="#{MyFormBean.email}" />

<!-- equivalent to html:password -->

<h:inputSecret id="pwd" binding="#{MyFormBean.pwd}" />

...

</s:form>

Usage Restrictions

This tag isn’t “inherited” if you use a JSP include. You must put this tag on each and every JSP and JSP fragment that you want rendered as XHTML.

Attributes

None.

Examples

<html:xhtml/> at the start of the page is all you need.

Equivalents

None.

The Bean Tag Library

The Bean tag library has tags for reading the properties of JavaBeans and for writing text. There are two reasons why you’d use the Bean tags instead of hard-coding text into your JSPs. The first is to enable internationalization, and the second is to avoid using scriptlets.

Table C-10 gives a synopsis of tags in the Bean library, based on Apache's documentation. Refer to www.apache.org/licenses/LICENSE-2.0 for a copy of the Apache License.

Table C-10. Synopsis of the Bean Tag Library

Struts-EL Tags for the Bean Tag Library

Only the following tags in the Bean library have EL-enabled versions: include, message, page, resource, size, and struts. (Note: EL-enabled tags are those that allow you to use EL expressions. Refer to Chapter 10 for examples.)

cookie/header/parameter

Each exposes a scripting variable based on the value of the specified cookie/header/ parameter.

Usage Restrictions

The id and name attributes are required.

Attributes

•name:The name of the cookie/header/parameter to retrieve.

•id: The name of the exposed variable. Scriptlets and other custom tags will be able to access properties of the cookie/header/parameter using this name.

•value: The default value to return in case the cookie/header/parameter of the given name can’t be found.

•multiple: Specifies how multiple cookies/headers/parameters with the same name are to be handled. The exact value of this attribute is unimportant. If the multiple attribute is present, then the variable exposed by id is an array of the corresponding type (Cookie[]/String[]/String[]). If multiple is not present, then the first occurring cookie/header/parameter is bound to the exposed variable.

Examples

Consider the following URL:

http://www.kenyir.org/mypage.jsp?command=test&action=save&id=12345

Here’s how to expose the parameter named command on the requested URL:

<bean:parameter name="command" id="cmd" value="" /> Command is: <%=cmd%>

If there were more than one parameter named command, for example:

http://www.kenyir.org/mypage.jsp?command=print&command=save

you’d access them all in this way:

<bean:parameter name="command" id="cmd" value="" multiple="true"/> <logic:iterate name="cmd" id="aCommand">

<bean:write name="aCommand"/> </logic:iterate>

The other tags (header and cookie) have similar examples.

Equivalents

The JSTL <c:set> is a replacement for these tags.

Here’s how to use <c:set> as an equivalent tag for the case where the multiple attribute is not specified. The exposed variable is called myVar* and the corresponding name of the cookie/header/parameter is always myAttr.

<c:set var="myVar1" value="${cookie.myAttr}" /> <c:set var="myVar2" value="${header.myAttr}" /> <c:set var="myVar3" value="${param.myAttr}" />

If the multiple attribute is specified, then you’d use one of the following instead:

<c:set var="myVar4" value="${pageContext.request.cookies.myAttr}" /> <c:set var="myVar5" value="${headerValues.myAttr}" />

<c:set var="myVar6" value="${paramValues.myAttr}" />

Note that there is also a <c:remove> to delete a declared variable.

define

This tag exposes a variable based on data from (1) a given String, or (2) another JavaBean. Scriptlets and other tags can access this exposed variable like any other. This might not seem useful, but it is. Refer to the examples for details.

Refer also to the entries for cookie/header/parameter and page, which are related tags.

Usage Restrictions

The id attribute is required as the exposed variable’s name. You also need to either specify name/property/scope, or value, or nest the exposed variable’s value in the body of the

<bean:define> tag.

Also, note that you can define a variable only once. Attempting to define a new variable with the same name on the same page will result in an Exception being thrown.

Attributes

•id: The name of the exposed variable. Scriptlets and other custom tags will be able to access the new variable using this name.

•name/property/scope: These attributes are used to locate an object to expose, with the given name and optional property and scope. If scope isn’t specified, all scopes are searched for the named object.

•value: The String value to expose. This binds the variable exposed using the id attribute to the String specified by the value attribute.

•toScope: The scope on which to place the new variable. Can be page, request, session, or application.

•type: The fully qualified classname for the variable exposed using the id attribute. If not specified, java.lang.String is used when you also specify the value attribute. It is also implied when you use the nested technique (see the examples). If you use the name/property/scope method, then the implicit classname is java.lang.Object.

Examples

Here are a few examples of how you’d expose a String or variable using <bean:define>:

<bean:define id="myVar1" name="myAttr" property="myProp" scope="session"/>

<bean:define id="myVar2" name="myAttr" scope="session"/> <bean:define id="myVar3" value="Hello World" toScope="request" /> <bean:define id="myVar4">Here's looking at you kid!</bean:define>

<bean:define id="myVar5">

<!-- myAttr.getMyProp() must never return null --> <bean:write name="myAttr" property="myProp"/>

</bean:define>

In the last example, if myAttr.getMyProp() returned null, then an exception would be thrown. Otherwise, myVar5 is equal to the value of myAttr.getMyProp() at the time it was called.

You can use <bean:define> to help you localize validations (see Chapter 12) if you use it with Struts-EL tags. Recall that in Chapter 12’s treatment of the subject of localizing validations, we explained that you could use the trick of embedding the localized format String along with the form data (refer to Listing 12-3). An Action was used to populate the

Usage Restrictions

You must specify either the key attribute or the name/property/scope combination.

Attributes

•key: The key of the message resource to display. If the locale/bundle combination isn’t specified, then the default message resource file and user’s current locale are used to determine which message resource to display.

•name/property/scope: These attributes are used to derive a key, based on an object with the given name and optional property and scope. If scope isn’t specified, all scopes are searched for the named object.

•locale/bundle: These attributes are used to specify a different Locale object or message resource file. locale specifies a key that can be used to look up the Locale object stored on the current session. The bundle attribute is explained in more detail in the following subsection.

•arg0/arg1/arg2/arg3/arg4: These are the values of the first, second, third, fourth, and fifth replacement parameters.

Using Multiple Message Resource Files

Struts allows you to declare more than one message resource file (that is, more than one Application.properties file, for the same locale). Each such message resource file is given a unique name, referred to in the Struts tags using the bundle attribute. The default message resource file has no name, and it is the one that is used if the bundle attribute isn’t specified.

You should be aware that there are problems with using multiple message resource files:

•There are reported problems getting it to work with the Validator framework.

•It makes maintenance more difficult. This is because in addition to specifying the key, you’d have to indicate the bundle name (if it’s not the default one). If you later decide to move a message from one file to another (common if you’re consolidating an app to ensure uniformity of displayed messages or prompts), then you’d have to change the bundle value of every tag that used that particular message.

So you should try to avoid using this feature if possible.

An alternative is to use a naming convention for keys, like the dot naming convention (e.g., app.error.prompt.login) I’ve used for message keys throughout this book. This lets you to create separate namespaces, and so obviates the need for multiple message resource files.