Java-Struts2

Struts 2 and OGNL

2008-09-25T00:35:00.000-07:00

!The article has been taken from the book 'Struts 2 in Action'.If you have already read the book you need not to read it again
Throughout Struts 2 web applications, a need exists to link the Java runtime with the text-based world of HTML, HTTP, JSP, and other text-based view-rendering technologies. There must be a way for these text-based documents to reference runtime data objects in the Java environment. A common solution to this problem is the use of expression languages. As we’ve seen, Struts 2 uses OGNL for this purpose. We’ll now take the opportunity to cover the features of this expression language that you’ll most likely need to use in Struts 2 development.
Here are details
Page 1
Page 2
Page 3
Page 4
Page 5

OGNL 5

2008-09-25T00:19:00.000-07:00

<--PREVIOUS

Advanced expression language features
As we’ve indicated, OGNL is a full-featured expression language. In fact, its features rival that of some fullfledged programming languages. In this section, we give a brief summary of some of the advanced features that you might use in a pinch. Some of these things are basic features of OGNL, but advanced in the context of Struts 2 usage. Take our terminology with a grain of salt. Also, we’ll make little effort to introduce use cases for these features. We consider their usage to be nonstandard practice. With that said, we also know that these power tools can save the day on those certain occasions that always seem to occur.

LITERALS AND OPERATORS
Like most languages, the OGNL expression language supports a wide array of literals. Table below summarizes these literals.

The only thing out of the ordinary would be the usage of both single and double quotes for string literals. Note, however, that a string literal of a single character must use double quotes, or it’ll be interpreted as a char literal. Table below shows the operators.

As you can see, all the usual suspects are here. This would probably be a good time to note that the OGNL expression language also allows multiple comma-separated expressions to be linked in a single expression. The following snippet demonstrates this process:

user.age = 10, user.name = "chad", user.username

This relatively meaningless example demonstrates an expression that links three subexpressions. As with many languages, each of the first two expressions executes and passes control on to the next expression. The value returned by the last expression is the value returned for the entire expression. Now we’ll see how to invoke methods with OGNL.

CALLING METHODS
One power that many a JSP developer has wished for is the ability to call methods from the expression language. Until recently, this was rare. Actually, even the simplest property reference involves a method call. But those simple property references can invoke methods based on JavaBeans conventions. If the method you want to invoke doesn’t conform to JavaBeans conventions, you’ll probably need the OGNL method invocation syntax to get to it. This can sometimes get you out of a jam. It can also be useful in calling utility methods on helper beans. Table below shows how it works

Note that in this table we assume that a random number generator bean, named utilityBean, has been pushed onto the ValueStack prior to the evaluation of these OGNL expressions. With this bean in place, you can omit the object name in the OGNL expression, because it resolves to the ValueStack by default. First, we invoke the makeRandomNumber() method as you might expect. In the second example, we show that you can even use a full method invocation syntax to access JavaBeans properties, though you don’t have to. The result is no different than when using the simpler property notation.

We should note that these method invocation features of the OGNL expression language are turned off during the incoming phase of Struts 2 data transfer. In other words, when the form input field names are evaluated by the params interceptor, method invocations, as well as some other security-compromising features of the expression language, are completely ignored. Basically, when the params interceptor evaluates OGNL expressions, it’ll only allow them to point to properties onto which it should inject the parameter values. Nothing else is permitted.

ACCESSING STATIC METHODS AND FIELDS
In addition to accessing instance methods and properties, you can also access static methods and fields with the OGNL expression language. There are two ways of doing this. One requires specifying the fully qualified class name, while the other method resolves against the ValueStack. The syntax that takes the full class name is @[fullClassName]@[property or methodCall]. Here are examples of using full class names to access both a static property and a static method:

@manning.utils.Struts2PortfolioConstants@USER
@manning.utils.PortfolioUtilityBean@startImageWrapper()

Besides the @ signs, these are no different than normal property specification or method invocation. As we said, you can forgo specifying the class name if and only if your property or method will resolve on the ValueStack. Here we have the same two examples, but they assume that some object on the ValueStack exposes what they need. The syntax replaces the class name with the vs symbol, which stands for ValueStack:

@vs@USER
@vs@startImageWrapper()

That wraps up our coverage of some of the advanced features of OGNL. You’ll probably find yourself coming back to this quick reference in the future as you butt heads with some odd wall or two. Again, we recommend taking it easy on the OGNL power tools. However, we’re compelled to tell you that OGNL contains even more powerful features than we’ve felt comfortable divulging. For the full details, we refer you directly to the primary OGNL documentation found at www.ognl.org.

<--PREVIOUS

OGNL 4

2008-09-25T00:01:00.000-07:00

<--PREVIOUS

NEXT--->

WORKING WITH MAPS
OGNL also makes referencing properties and elements of maps delightfully simple.
Table below shows a variety of syntax idioms for referencing Map elements and properties.

As you can see, you can do a lot with maps. The main difference here is that, unlike Lists, the value in the index box must be an object. If the value in the box is some sort of numeric data that would map to a Java primitive, such as an int, then OGNL automatically converts that to an appropriate wrapper type object, such as an Integer, to use as the key. If a string literal is placed in the box, that becomes a string object which will be used for the key. The last row in the table shows a special syntax for maps with strings as keys. If the key is a string, you may use this simpler, JavaBeans-style property notation.
As for other object types that you might use as a key, you ultimately have the full power of OGNL to reference objects that might serve as the key. The possibilities are beyond the capacity of the table format. Note that, as with the List syntax, the direct reference to the name property on the uncast map element depends on the configuration of the OGNL type conversion to know the specific element type of the map.
You can also create Maps on the fly with the OGNL literal syntax. Table below demonstrates this flexible feature.

As you can see, the syntax for creating a Map literal is similar to that for creating a List literal. The main difference is the use of the # sign before the leading brace.

Warning
OGNL uses the # sign in a few different ways. Each is distinct. The uses are completely orthogonal, so you shouldn’t be confused as long as you’re alert to the fact that they’re different use cases. In particular, this isn’t the same use of the # sign as we saw when specifying a nonroot object from the ActionContext for an expression to resolve against. We’ll also see another use of the # sign in a few moments.

Dynamic maps are especially useful for radio groups and select tags. The Struts 2 tag libraries come with special tags for creating user interface components. Just note that you can use literal maps to feed values into some of the UI components. If you wanted to offer a true/false selection that displays as a Yes/No choice, #{true : 'Yes', false : 'No'} would be the value for the list attribute. The value for the value attribute would evaluate to either true or false.

FILTERING AND PROJECTING COLLECTIONS
OGNL supports a couple of special operations that you can conduct on your collections. Filtering allows you to take a collection of objects and filter them according to some rule. For instance, you could take a set of users and filter them down to only those who’re more than 20 years old. Projection, on the other hand, allows you to transform a collection of objects according to some rule. For instance, you could take a set of user objects, having both first and last name properties, and transform it into a set of String objects that combines the first and last name of each user into a single string. To clarify, filtering takes a Collection of size N and produces a new collection containing a subset of those elements ranging from size 0 to size N. On the other
hand, projecting always produces a Collection with exactly the same number of elements as the original Collection; projecting produces a one-for-one result set.

The syntax for filtering is as follows:

collectionName.{? expression }

In the expression, you can use #this to refer to the object from the collection being evaluated. This is another distinct use of the # sign. The syntax for projection is as follows:

collectionName.{ expression }

Table below shows some examples of both of these useful operations in action.

As you can see, each filtering or projection simply returns a new collection for your use. This convenient notation can be used to get the most out of a single set of data. Note that you can combine filtering and projection operations. That about covers it for aspects of OGNL that are commonly used in Struts 2. In the next section, we’ll cover some of the advanced features that might help you out in a pinch, but, still, we recommend keeping it simple unless you have no choice.

<--PREVIOUS

NEXT--->

OGNL 3

2008-09-22T20:07:00.000-07:00

<--PREVIOUS

NEXT--->

WORKING WITH JAVA COLLECTIONS
Java Collections are a mainstay of the Java web developer’s daily workload. While the JavaBeans specification has always supported indexed properties, working with actual Java Collections, while convenient in the Java side, has always been a hassle in contexts such as JSP tags. One of the great things about the OGNL expression language is its simplified handling of Collections. We’ll now summarize the OGNL syntax used to reference these properties.

WORKING WITH LISTS AND ARRAYS
References to lists and arrays share the same syntax in OGNL. Table below summarizes the basic syntax to access list or array properties.
As the table demonstrates, the syntax for referencing elements or properties of
lists and arrays is intuitive. Basically, OGNL uses array index syntax for both. This
makes perfect sense, due to the ordered, indexed nature of lists.

A couple of things warrant remarks. First, the reference to the name property of a list element assumes something important. As we know, Java Lists are type-agnostic. In Java, we always have to cast the element to the appropriate type, in this case User, before we try to reference the name property. This syntax assumes that has been done. We should also note that you can reference other properties, such as length and size, of arrays and lists. In particular, note that OGNL makes the List class’s non-JavaBeans-conformant size method answer to a simple property reference. This is something nice that OGNL provides as free service to its valued customers!
OGNL also allows you to create List literals. This can be useful if you want to directly create a set of values to feed to something like a select box. Table below shows the syntax for creating these literals.

You probably only want to do this with trivial data, since creating complex data in the view layer would make a mess. Nonetheless, sometimes this will be the perfect tool for the job.

<--PREVIOUS

NEXT--->

OGNL 2

2008-09-22T19:32:00.000-07:00

<--PREVIOUS

NEXT--->

Expression language features commonly used in Struts 2
First, we should review the most common uses of the OGNL expression language in Struts 2 development. In this section, we’ll look at how the expression language serves its purpose for most daily development. Basically, we use it to map the incoming data onto your ValueStack objects, and we use it in tags to pull the data off of the ValueStack while rendering the view. Let’s look at the expression language features most commonly used in this work.

REFERENCING BEAN PROPERTIES
First of all, we need to define what makes an expression. The OGNL expression language refers to something called a chain of properties. This concept is simple.
Take the following expression:

person.father.father.firstName

This property chain consists of a chain of four properties. We can say that this chain references, or targets, the firstName property of person’s grandfather. You can use this same reference both for setting and getting the value of this property, depending on your context.

SETTING OR GETTING?
When we use OGNL expressions to name our form input parameters, we’re referring to a property that we’d like to have set for us. The following code snippet shows the form from our Struts 2 Portfolio application’s Registration.jsp page:

<s:form action="Register">
<s:textfield name="username" label="Username"/>
<s:password name="password" label="Password"/>
<s:textfield name="portfolioName" label="Enter a portfolio name."/>
<s:submit/>
</s:form>

The name of each input field is an OGNL expression. These expressions refer to, for example, the username property exposed on the root OGNL object. As we’ve just learned, the root object is our ValueStack, which probably contains our action object and perhaps a model object. When the params interceptor fires, it’ll take this expression and use it to locate the property onto which it should set the value associated with this name. It’ll also use the OGNL type converters to convert the value from a string to the native type of the target property. There is one common complication that arises when the framework moves data onto the properties targeted by the OGNL expressions.
Take the deeper expression:

user.portfolio.name

If a request parameter targets this property, its value will be moved onto the name property of the portfolio object. One problem that can occur during runtime is a null value for one of the intermediate properties in the expression chain. For instance, what if the user hasn’t been created yet? If you recall, we’ve been omitting initialization for many of our properties in our sample code. Luckily, the framework handles this. When the framework finds a null property in a chain that it needs to navigate, it’ll attempt to create a new instance of the appropriate type and set it onto the property. However, this requires two things on the developer’s part. First, the type of the property must be a class that conforms to the JavaBeans specification, in that it provides a no-argument constructor. Without this, the framework can’t instantiate an object of the type. Next, the property must also conform to the JavaBeans specification by providing a setter method. Without this setter, the framework would have no way of injecting the new object into the property. Keep these two points in mind and you’ll be good to go.
In addition to targeting properties onto which the framework should move incoming data, we also use OGNL when the data leaves the framework. After the request is processed, we use the same OGNL expression to target the same property from a Struts 2 tag. Recall that the domain model data stays on the ValueStack from start to finish. Thus, tags can read from the same location that the interceptors write.
The following snippet shows the property tag doing just this:

<h5>Congratulations! You have created </h5>
<h3>The <s:property value="portfolioName" /> Portfolio</h3>

In this snippet, we see that the Struts 2 property tag takes an OGNL expression as its value attribute. This expression targets the property from which the property tag will pull the data for its rendering process, a simple process where it merely converts the property to a string and writes it into the page. As you can see, OGNL expressions, as commonly used in Struts 2, serve as pointers to properties. Whether the use case is writing to or reading from that property is up to the context. Though not nearly as common, you can also use the fuller features of the OGNL expression language, operators in particular, to write self-contained expressions that, for instance, set the data on a property themselves. But, as this is outside of the normal Struts 2 use case, we’ll only discuss such features in the advanced section.

<--PREVIOUS

NEXT--->

OGNL

2008-09-22T19:22:00.000-07:00

INDEX

Struts2 and OGNL
Throughout Struts 2 web applications, a need exists to link the Java runtime with the text-based world of HTML, HTTP, JSP, and other text-based view-rendering technologies. There must be a way for these text-based documents to reference runtime data objects in the Java environment. A common solution to this problem is the use of expression languages. As we’ve seen, Struts 2 uses OGNL for this purpose. We’ll now take the opportunity to cover the features of this expression language that you’ll most likely need to use in Struts 2 development.

What is OGNL?
The Object-Graph Navigation Language exists as a mature technology completely distinct from Struts 2. As such, it has purposes and features much larger than its use within Struts 2. OGNL is an expression and binding language. In Struts 2, we use the OGNL expression language to reference data properties in the Java environment, and we use OGNL type converters to manage the type conversion between HTTP string values and the typed Java values.
In this last section, we’ll try to summarize the syntax and some of the more useful features of the OGNL expression language. First we’ll cover the syntax and features most commonly used in Struts 2 development. Then we’ll cover some of the other OGNL features that you might find handy. OGNL has many of the features of a full programming language, so you’ll find that most everything is possible. Also note that this section doesn’t try to be a complete reference to OGNL. If you want more OGNL power, visit the website at www.ognl.org for more information.
Keep those JSPs clean! While OGNL has much of the power of a fullfeatured language, you might want to think twice before squeezing the trigger. It’s a well-established best practice that you should keep business logic out of your pages. If you find yourself reaching for the OGNL power tools, you might well be pulling business logic into your view layer. We’re not saying you can’t do it, but we recommend giving it a moment’s thought before complicating your view pages with too much code-style logic. If you’re getting complex in your OGNL, ask yourself if what you’re doing should be done in the action or, at least, encapsulated in a helper bean that you can use in your page.

NEXT--->

Param tag

2008-09-22T18:52:00.000-07:00

The last tag we’ll discuss has already been used throughout this chapter. The param tag does nothing by itself, but at the same time it’s one of the more important tags. It not only serves an important role in using many of the tags covered in this chapter, it’ll also play a role in many of the UI component tags, Table below lists the attributes you’re now familiar with.

Using the param tag has already been established in this chapter. In particular, our coverage of the bean tag showed a couple of use cases for the param tag, including as a means for passing parameters into your own custom utility objects. As long as you have the general idea, it’s just a matter of perusing the APIs to see which tags can take parameters. Toward this end, it’s always a good idea to consult the online documentation of the Struts 2 tags to see if a given tag can take a parameter of some sort.

The i18n and text tags

2008-09-22T01:04:00.000-07:00

Many applications need to work in multiple languages. The process of making this happen is called internationalization, or i18n for short. (There are 18 letters between the I and the N in the word internationalization.) Chapter 11 discusses Struts 2’s internationalization support in detail, but we’d like to take a moment to detail the two tags that are central to this functionality: the i18n tag and the text tag.
The text tag is used to display language-specific text, such as English or Spanish, based on a key lookup into a set of text resources. This tag retrieves a message value from the ResourceBundles exposed through the framework’s own internationalization mechanisms. For now, we’ll just note the usage of the tag; it takes a name attribute that specifies the key under which the message retrieval should occur. The framework’s default Locale determination will determine the Locale under which the key will be resolved.

You can also name an ad hoc ResourceBundle for resolving your text tags. If you want to manually specify the ResourceBundle that should be used, you can use the i18n tag. Table below lists the attributes of the i18n tag.

Here’s a quick example that shows how to set the ResourceBundle with the i18n tag and then extract a message text from it with the text tag:

<s:i18n name="manning.chapterSix.myResourceBundle_tr">
In <s:text name="language"/>,
<s:text name="girl" var="foreignWord"/>
</s:i18n>
"<s:property value="#foreignWord"/>" means girl.

The i18n tag simply specifies a resource bundle to use. The bundle is only used during the body of the tag. However, as our example demonstrates, you can “persist” a message from the bundle using the text tag’s var attribute to set the message to the ActionContext as a named reference. This usage of the var attribute should be more familiar by now. The first text tag writes the message associated with the key “language” directly to the output. The second text tag stores the message associated with the key “girl” under the reference name “foreignWord”.
These tags are simple, but seem out of context without full knowledge of the uiltininternationalization features of Struts 2. In particular, you’ll need to know how the framework locates, loads, and uses properties file ResourceBundles.

URL Tag

2008-09-22T00:58:00.000-07:00

When you’re building web applications, URL management is a central task. Struts 2 provides a URL tag to help you do this. The tag supports everything you might want to do with a URL, from controlling parameters to automatically persisting sessions in the absence of cookies. Table below lists its attributes.

Here are a couple of examples. First we look at a simple case:

URL = <s:url value="IteratorTag.action"/> <a href='<s:url value="IteratorTag.action" />'> Click Me </a>

And here’s the output markup:
URL = IteratorTag.action

The URL tag just outputs the generated URL as a string. First we display it for reference. Then we use the same markup to generate the href attribute of a standard anchor tag. Note that we set the target of the URL with the value attribute. This means we must include the .action extension ourselves. If we want to target an action, we should probably use the action attribute, as seen in the next example:

URL = <s:url action="IteratorTag" var="myUrl"> <s:param name="id" value="2"/> </s:url> <a href='<s:property value="#myUrl" />'> Click Me </a>

Now, let’s see the markup generated by these tags:
URL =

<a href='/manningHelloWorld/chapterSix/IteratorTag.action?id=2'> Click Me </a>

As you can see, the URL tag didn’t generate any output in this example. This happened because we used the var attribute to assign the generated URL string to a reference in the ActionContext. This helps improve the readability of the code. In this example, our URL tag, with its param tags, has become unwieldy to embed directly in the anchor tag. Now we can just pull the URL from the ActionContext with a property tag and some OGNL. This is also useful when we need to put the URL in more than one place on the page.
The param tag used in this example specifies querystring parameters to be added to the generated URL. You can see generated querystring in the output. Note that you can use the includeParams attribute to specify whether parameters from the current request are carried over into the new URL. By default this attribute is set to get, which means only querystring params are carried over. You can also set it to post, which causes the posted form parameters to also be carried over. Or you can specify none.
<a href='IteratorTag.action'> Click Me </a>

Include Tag

2008-09-22T00:44:00.000-07:00

Whereas JSP has its own include tag, <jsp:include>, Struts 2 provides a version that integrates with Struts 2 better and provides more advanced features. In short, this tag allows you to execute a Servlet API–style include. This means you can include the output of another web resource in the currently rendering page. One good thing about the Struts 2 include tag is that it allows you to pass along request parameters to the included resource.
This differs from the previously seen action tag, in that the include tag can reference any servlet resource, while the action tag can include only another Struts 2 action within the same Struts 2 application. This inclusion of an action stays completely within the Struts 2 architecture. The include tag can go outside of the Struts 2 architecture to retrieve any resource available to the web application in which the Struts 2 application is deployed. This generally means grabbing other servlets or JSPs. The include tag may not make a lot of sense unless you’re pretty familiar with the Servlet API. Again, the Servlet Specification is recommended reading: http://java.sun.com/products/servlet/download.html.
Table below lists the sole attribute for the include tag.

We won’t show a specific example of the include tag, as its use is straightforward. When using the include tag, you should keep in mind that you’re including a JSP, servlet, or other web resource directly. The semantics of including another web resource come from the Servlet API. The include tag behaves similarly to the JSP include tag. However, it’s more useful when you’re developing with Struts 2, for two reasons: it integrates better with the framework, and it provides native access to the ValueStack and a more extensible parameter model. What does all of this mean?

Let’s start with the framework integration. For example, your tag can dynamically define the resource to be included by pulling a value from the ValueStack using the %{ ... } notation. (You have to force OGNL evaluation here, as the value attribute is of type String and would normally be interpreted as a string literal.) Similarly, you can pass in querystring parameters to the included page with the <s:param> tag (discussed in a moment). This tag can also pull values from the ValueStack. This tight integration with the framework makes the Struts 2 include tag a powerful choice.
Another advantage to choosing the Struts 2 include tag over the native JSP version is plain-old user-friendliness. For example, it’ll automatically rewrite relative URLs for you. If you want to include the URL ../index.jsp, you’re free to do so even though some application servers don’t support that type of URL when using the JSP include tag. The Struts 2 include tag will rewrite ../index.jsp as an absolute URL based on the current URL where the JSP is located.

If Else Tag

2008-09-22T00:37:00.000-07:00

Not many languages, of any sort, fail to provide the familiar if and else control logic.The if and else tags provide these familiar friends for the Struts 2 developer. Using them is as easy as you might suspect. As you can see in table below, there’s just one attribute, a Boolean test.

Here’s an example of using them. You can put any OGNL expression you like in the test.

<s:if test="user.age > 35">This user is too old.</s:if> <s:elseif test="user.age < 35">This user is too young</s:elseif> <s:else>This user is just right</s:else>

Here we conduct a couple of tests on a user object exposed by our action and, ultimately,found on the ValueStack. The tests are simple Boolean expressions; you can
chain as many of the tests as you like.That was easy enough. Indeed, the if and else tags are as simple as they seem, and remain that way in use. We still have a few useful tags to cover, and we’ll hit them in the next section, which covers miscellaneous tags.

The iterator tag

2008-09-22T00:22:00.000-07:00

Other than the property tag, the other most commonly used tag in Struts 2 is the iterator tag. The iterator tag allows you to loop over collections of objects easily. It’s designed to know how to loop over any Collection, Map, Enumeration, Iterator, or array. It also provides the ability to define a variable in the ActionContext, the iterator status, that lets you determine certain basic information about the current loop state, such as whether you’re looping over an odd or even row. Table below provides the attributes for the iterator tag.

We already saw the iterator tag in action when we looked at the bean tag. Now we’ll
take a closer look. The chapter 6 sample application includes an example that loops
over a set of the Users of the Struts 2 Portfolio. Here’s the markup from the result page:

<s:iterator value="users" status="itStatus">
<li>
<s:property value="#itStatus.count" />
<s:property value="portfolioName"/>
</li>
</s:iterator>

As you can see, it’s straightforward. The action object exposes a set of users and the iterator tag iterates over those users. During the body of the tag, each user is in turn placed on the top of the ValueStack, thus allowing for convenient access to the user’s properties. Note that our iterator also declares an IteratorStatus object by specifying the status attribute. Whatever name you give this attribute will be the key for retrieving the iterator status object from the ActionContext, with an OGNL expression such as #itStatus. In this example, we use the iterator status’s count property to get a sequential list of our users. The output is shown in figure below

We should probably take a minute to see what else the IteratorStatus can provide
for us.

USING ITERATORSTATUS
Sometimes it’s desirable to know status information about the iteration that’s taking place. This is where the status attribute steps in. The status attribute, when defined,provides an IteratorStatus object available in the ActionContext that can provide simple information such as the size, current index, and whether the current object is in the even or odd index in the list. The IteratorStatus object can be accessed through the name given to the status attribute. Table below summarizes the information that can be obtained from the IteratorStatus object.

As you can see, this list provides just the kind of data that can sometimes be
hard to come by when trying to produce various effects within JSP page iterations.
Happy iterating!

Action tag

2008-09-22T00:02:00.000-07:00

This tag allows us to invoke another action from our view layer. Use cases for this might not be obvious at first, but you’ll probably find yourself wanting to invoke secondary actions from the result at some point. Such scenarios might range from integrating existing action components to wisely refactoring some action logic. The practical application of the action tag is simple: you specify another action that should be invoked. Some of the most important attributes of this tag include the executeResult attribute, which allows you to indicate whether the result for the secondary
action should be written into the currently rendering page, and the name and namespace attributes, by which you identify the secondary action that should fire. By default, the namespace of the current action is used. Table below contains the details of the important attributes.

Here’s an example that chooses to include the secondary action’s result:

<h3>Action Tag</h3> <h4>This line is from the ActionTag action's result.</h4> <s:action name="TargetAction" executeResult="true"/>

Note that the default is to not include the result, so we have to change this by setting the executeResult attribute to true. The output looks like figure below.
One thing to note is that the result of the secondary action should probably be an HTML fragment if you want it to fit into the primary page.
Often, you might want the secondary action to fire, but not write a result. One
common scenario is that the secondary action, instead of writing to the page, will produce side effects by stashing domain data somewhere in the ActionContext. After control returns, the primary action can access that data. The following markup shows how to target an action in this fashion:

<h4>This line is before the ActionTag invokes the secondary action.</h4> <s:action name="TargetAction"/> <h4>Secondary action has fired now.</h4> <h5>Request attribute set by secondary action = </h5> <pre> <s:property value="#request.dataFromSecondAction"/></pre>

The execution of the secondary action is a bit of a side effect unless we reach back to get something that it produced. We retrieve a property that was set by the secondary action into the request map, just to prove that the secondary action fired. You can check the output yourself by visiting the chapter 6 sample code. Many times, however, a side effect may be just what you want. Note also that the secondary action can receive, or not receive, the request parameters from the primary request, according to the ignoreContextParams attribute.
That finishes up our coverage of data tags. In the next section, we’ll show how to introduce conditional logic to your page rendering with the control tags.

Bean tag

2008-09-21T23:43:00.000-07:00

The bean tag is like a hybrid of the set and push tags. The main difference is that you don’t need to work with an existing object. You can create an instance of an object and either push it onto the ValueStack or set a top-level reference to it in the Action-Context. By default, the object will be pushed onto the ValueStack and will remain there for the duration of the tag. In other words, the bean will be on the ValueStack for the execution of all tags that occur in between the opening and closing tags of the bean tag. If you want to persist the bean longer than the body of the tag, you can specify a reference name for the bean with the var attribute. This reference will then exist in the ActionContext as a named parameter accessible with the # operator for the
duration of the request.
There are a few requirements on the object that can be used as a bean. As you might expect, the object must conform to JavaBeans standards by having a zero-argument constructor and JavaBeans properties for any instance fields that you intend to initialize with param tags. We’ll demonstrate all of this, including the use of param tags, shortly. First, table below details the attributes for the bean tag.

Our first example demonstrates how to create and store the bean as a named parameter in the ActionContext. In this case, we’ll create an instance of a utility bean that helps us simulate a for loop. This counter bean comes with Struts 2. For this example, we’ll create the bean and use the var attribute to store it in the ActionContext as a named parameter. The following markup shows how this is done:

<s:bean name="org.apache.struts2.util.Counter" var="counter"> <s:param name="last" value="7"/> </s:bean> <s:iterator value="#counter"> <li><s:property/></li> </s:iterator>
Figure below how this markup will render in the result page.

Now let’s look at how it works. The bean tag’s name attribute points to the class that should be instantiated. The var attribute, repeating a common Struts 2 tag API pattern, specifies the reference name under which the bean will be stored in the ActionContext. In this case, we call the bean counter and then refer to that bean instance in the iterator tag’s value attribute with the appropriate OGNL. Since the bean is in the ActionContext, rather than on the ValueStack, we need to use the # operator to name it, resulting in the OGNL expression #counter. The bean tag is the first of a few tags we’ll explore that are parameterized. In the case of the counter, we can pass in a parameter that sets the number of elements it will contain, in effect setting the number of times the iterator tag will execute its body markup.

TIP:
The var attribute occurs in the usage of many Struts 2 tags. Any tag that creates an object, the bean tag being a good example, offers the var attribute as a way to store the object under a name in the ActionContext. The name comes from the value given to the var attribute. Most tags that offer the var attribute make it optional; if you don’t want to store the created object in the ActionContext, it will simply be placed on the top of the ValueStack, where it’ll remain during the body of the tag.
WARNING!
If you’re using a version of Struts 2 that is older than 2.1, the var attribute should be replaced with the id attribute.

Now that the counter bean has been created and stored, we can use it from the Struts 2 iterator tag to create a simulation of for loop-style logic. The bean tag doesn’t have to be used with the iterator tag; it’s in this example because the counter bean is meant to be used with the iterator tag. The counter bean works in combination with the iterator tag, which we’ll cover shortly, to provide a pseudo for loop functionality. Generally, the iterator tag iterates over a Collection, thus its number of iterations is based upon the number of elements in the Collection. For a for loop, we want to specify a number of iterations without necessarily providing a set of objects. We just
want to iterate over our tag’s body a certain number of times. The counter bean serves as a fake Collection of a specified number of dummy objects that allows us to control the number of iterations. In the case of our example, we do nothing more than print a number to the result stream during each iteration. Note that we use the property tag without any attributes; this idiom will simply write the top property on the ValueStack to the output.

NOTE:
The bean tag allows you to create any bean object that you might want to use in the page. If you want to make your own bean to use with this tag, just remember that it needs to follow javaBeans conventions on several important points. It has to have no-argument constructor, and it must expose JavaBeans properties for any parameters it’ll receive with the param tag, such as the counter bean’s last parameter.

Now, let’s look at how to use the bean tag to push a newly created bean onto the ValueStack rather than store it in the ActionContext. While we’re at it, we’ll further demonstrate the use of the param tag to pump parameters into our homeroasted bean. This is all simple. To use the ValueStack as the temporary storage location for our bean, we just use an opening-and-closing-style tag configuration. All tags inside the body of the bean tag will resolve against a ValueStack that has an instance of our JokeBean on top. Here’s the example:

<s:bean name="manning.utils.JokeBean" > <s:param name="jokeType">knockknock</s:param> <s:property value="startAJoke()"/> </s:bean>

In this example, also from the chapter 6 sample code, we create an instance of a utility bean that helps us create jokes. If you look at the sample application, you’ll see that this outputs the first line of a joke—“knock knock.” Though inane, this bean does demonstrate the sense of utility beans. If you want to provide a canned joke component to drop into numerous pages, something that unfortunately does exist in the real world, you could embed that functionality into a utility bean and grab it with the bean tag whenever you liked. This keeps the joke logic out of the core logic of the action logic. This markup demonstrates using the bean tag to push the bean onto the
ValueStack rather than place it as a named reference in the ActionContext. Note that we no longer need to use the var attribute to specify the reference under which the bean will be stored. When it’s on top of the ValueStack, we can just refer to its properties and methods directly. This makes our code concise. The bean is automatically popped from the stack at the close tag.
Using the bean is easy. In this case, we use the OGNL method invocation syntax, startAJoke(). We do this just to demonstrate that the bean tag doesn’t have to completely conform to JavaBeans standards—startAJoke() is clearly not a proper getter.
Finally, note that we pass a parameter into our JokeBean that controls the type of joke told by the bean. This parameter is automatically received by our bean as long as the bean implements a JavaBeans property that matches the name of the parameter. If you look at the source code, you can see that we’ve done this. FYI: this joke bean also supports an "adult" joke mode, but you’ll probably be disappointed; it’s quite innocuous.
The bean tag is ultimately straightforward. What you want to be clear about is the difference between the use of the var attribute to create a named reference in the ActionContext, and the use of the opening and closing tags to work with the bean on the ValueStack. The real trick here is in understanding the ValueStack, Action-Context, and how OGNL gets to them. That’s why we began this chapter with a thorough introduction to these concepts. If you’re confused, you might want to refer back to those earlier sections.
With those fundamental concepts in place, the conventions of the bean tag, and
other similar tags, should be straightforward enough. If you have all this straight, congratulate
yourself on a mastery of what some consider to be the most Byzantine aspect of Struts 2

Push tag

2008-09-21T23:20:00.000-07:00

Whereas the set tag allows you to create new references to values, the push tag allows you to push properties onto the ValueStack. This is useful when you want to do a lot of work revolving around a single object. With the object on the top of the ValueStack, its properties become accessible with first-level OGNL expressions. Any time you access properties of an object more than a time or two, it’ll probably save a lot of work if you push that object onto the stack. Table 6.4 provides the attribute for the push tag.

Here’s an example of the usage:

<s:push value="user">
This is the "<s:property value="portfolioName"/>" portfolio,
created by none other than <s:property value="username"/>
</s:push>

This push tag pushes a property named user, which is exposed by the TagDemo action as a JavaBeans property, onto the top of the ValueStack. With the user on top of the stack, we can access its properties as top-level properties of the ValueStack virtual object, thus making the OGNL much simpler. As you can see, the push tag has a start tag and close tag. Inside the body of the tag, we reference the properties of the user object as top-level properties on the ValueStack. The closing tag removes the user from the top of the ValueStack.

Important :
The push tag, and even the set tag to a limited extent, can be powerful when trying to reuse view-layer markup. Imagine you have a JSP template that you’d like to reuse across several JSP result pages. Consider the namespace of the OGNL references in that JSP template. For instance, maybe the template’s tags use OGNL references that assume the existence of a User object exposed as a model object, as in ModelDriven actions. In this case, the template’s tags would omit the user property and refer directly to properties of the user, for example <s:property value="username"/>.
If you try to include this template in the rendering of a result whose action exposes a User object as a JavaBeans property, rather than a model object, then this reference would be invalid. It would need to be
<s: value="user.username"/>.
Luckily, the push tag gives us the ability to push the user object itself to the top of the ValueStack, thus making the top-level references of the template valid in the current action. In general,the push tag and the set tag can be used in this fashion.

Set tag

2008-09-21T23:02:00.000-07:00

In the context of this tag, setting means assigning a property to another name. Various reasons for doing this exist. An obvious use case would be taking a property that needs a deep, complicated OGNL expression to reference it, and reassigning, or setting, it to a top-level name for easier, faster access. This can make your JSPs faster and easier to read. You can also specify the location of the new reference. By default, the property becomes a named object in the ActionContext, alongside the ValueStack, session map, and company. This means you can then reference it as a top-level named object with an OGNL expression such as #myObject. However, you can also specify that the new reference be kept in one of the scoped maps that are kept in the ActionContext. Table below provides the attributes for the set tag

Here’s an example from the chapter 6 sample code:

<s:set name="username" value="user.username"/>
Hello, <s:property value="#username"/>. How are you?

In this case, we aren’t saving much by making a new reference to the username property.However, it illustrates the point. In this sample, the set tag sets the value from the user.username expression to the new reference specified by the name property. Since we don’t specify a scope, this new username reference exists in the default “action” scope—the ActionContext. As you can see, we then reference it with the # operator. Figure below shows the output.

In case you’re wondering what it looks like to set the new reference to a different scope, the following sets the new reference as an entry in the application scope map that is found in the ActionContext:

<s:set name="username" scope="application" value="user.username"/>
Hello, <s:property value="#application['username']"/>. How are you?

Note that we have to use the OGNL map syntax to get at the property in this case. We can’t say we’ve made any readability gains here, but we have managed to persist the data across the lifetime of the application by moving it to this map. It’s probably not a good idea to persist a user’s username to the application scope, but it does serve to demonstrate the tag functionality

Important :
The push tag, and even the set tag to a limited extent, can be powerful when trying to reuse view-layer markup. Imagine you have a JSP template that you’d like to reuse across several JSP result pages. Consider the namespace of the OGNL references in that JSP template. For instance, maybe the template’s tags use OGNL references that assume the existence of a User object exposed as a model object, as in ModelDriven actions. In this case, the template’s tags would omit the user property and refer directly to properties of the user, for example .
If you try to include this template in the rendering of a result whose action exposes a User object as a JavaBeans property, rather than a model object, then this reference would be invalid. It would need to be
.
Luckily, the push tag gives us the ability to push the user object itself to the top of the ValueStack, thus making the top-level references of the template valid in the current action. In general,the push tag and the set tag can be used in this fashion.

Property tag

2008-09-21T22:50:00.000-07:00

The property tag provides a quick, convenient way of writing a property into the rendering HTML. Typically, these properties will be on the ValueStack or on some other object in the ActionContext. As these properties can be of any Java type, they must be converted to strings for rendering in the result page. This conversion is handled by the framework’s type converters, which we covered in chapter 5. If a specific type has no converter, it’ll typically be treated as a string. In these cases, a sensible toString() method should be exposed on the class. Table below summarizes the most important attributes.

Datetimepicker setting today's date

2008-09-21T21:55:00.000-07:00

Here is a simple tip to initialize your datetimepicker with the current date.

For example this is your tag (Don't forget to add ajax theme in your head tag)

<s:datetimepicker label="Start Date" id="startTime" name="startTime" type="date" required="true"> </s:datetimepicker>

On body's onLoad call a java script function which will set the datatimepicker's value

function setValue() {
var picker = dojo.widget.byId("startTime");
//Date value
picker.setValue(new Date());
}

Known Issues :

You can not do the same thing with the datetimepicker 'Time' tag. For example if you have

<s:datetimepicker label="Start Date" id="startTime" name="startTime" type="time" required="true"> </s:datetimepicker>

Then you can not set the time on page load (If anyone has the solution please comment)

You can not use 'startDate' value attribute to set the initial value of the datetimepicker

doubleselect with full functionality

2008-09-16T21:50:00.000-07:00

Struts 2 doubleselect

First this is a simple example of loading dynamic contents through doubleselect then the deficiencies of doubleselect are discussed and the way to overcome them

Simple Example
Struts 2 provides a fantastic doubleselect tag, which allows you to specify two HTML select lists in such a way that the contents of the second list is dependent on the selection of the first (1). About a month ago, I came across a situation where this type of relationship was very advantageous, and set off towards the relevant Struts 2 documentation to learn how this mysterious tag worked. I found the list of attributes useful, but the examples at the bottom of the page left much to be desired (they're completely hard-coded). In fact, even after a good hour of searching, I couldn't find a solid example of the doubleselect tag that didn't hard-code both lists! Obviously it's much more useful to take advantage of the java back-end, and it took me two full hours of trial and error to finally figure out how to get my particular scenario working. What follows is a detailed example showing how to use the Struts 2 doubleselect tag to its fullest, for the next time I or anyone else wishes to make good use of it.

For our example, suppose you run some sort of automotive website, and would like to let the use specify the Make and Model of a car. The list of Makes should contain the car company, like Porsche, Ferrari or Lamborghini. The lists of Models should be the specific cars those companies make, like "911 Turbo" and "Boxster S" for the Porsche, "F430 Spyder" and "FXX" for Ferrari, etc. So when Porsche is selected in the first list, it's set of models will be shown in the second list. If we change the selection in the first list to Ferrari, the second list should update to contain only the Ferrari models. We also want to know what Make and Model the user has selected, and be able to set default selections in each list. This can actually be done with very little JSP syntax using the doubleselect tag:

    <%@ taglib prefix="s" uri="/struts-tags"%>

<s:form action="selectCar" method="POST">
        <s:doubleselect
name="makeId"         doubleName="modelId"
list="allMakes"       doubleList="models"
listKey="id"          doubleListKey="id"
listValue="name"      doubleListValue="name"
value="defaultItem"   doubleValue="doubleDefaultItem" />
    </s:form>

Of course, in addition to the jsp shown above, we need a struts.xml file, the struts action, a Make class and a Model class. It is assumed that you already know how to set up the struts.xml file and the basics of the struts action. Here's what we need in the other files:

The struts action must contain a list of Makes - the car companies, like Porsche, Lamborghini and Ferrari - and properties called makeId and modelId (which should match the type of id in the Make class) and defaultItem and doubleDefaultItem (which should match the type of name in the Make class).
The Make class must have a name, an id and a list of Models - this is the set of cars made by each company, so things like "911 Turbo" and "Boxster S" would be in the Porsche's model list, but the Ferrari model list would contain different things like "F430 Spyder" and "FXX".
The Model class needs only a name and an id.

When the page loads, here is how the doubleselect tag is interpreted:

The list attribute will call getAllMakes in the struts action, and use that list as the primary list. Similarly, doubeList calls getModels on each Make, and uses the resulting lists as the secondary lists.
The listValue attribute will call getName on each entry in the primary list, and use the resulting list of names to show on screen in the first menu. Similarly, doubleListValue calls getName on each entry in the secondary list, and stores them in memory for showing in the second menu.
The value and doubleValue attributes will call getDefaultItem and getDoubleDefaultItem in the action, and use the results to pre-select entries in each list. For example, if you wanted the default Make to be Ferrari, you would make sure getDefaultItem returns the Ferrari object.

When the form is submitted, the name and doubleName attributes will call setMakeId and setModelId in the action, and give them the values of listKey and doubleListKey respectively. So if Lamborghini is selected in the first list, and Murcielago in the second, the parameters passed in setMakeId and setModelId would be the id of the Make instance which has the name Lamborghini, and the id of the Model instance which has the name Murcielago.

So that's all there is to it! I hope this has been helpful, and saves a bit of time for the next person trying to implement a complex double-list system with back-end support.

(1) This functionality is provided using javascript which is automatically generated when Struts interprets the doubleselect tag. One downside to this approach is that it will clutter up your source quite a bit if you're using a large dataset, but this is unavoidable while using this tag.

Known Issues:
Although doubleselect is a very good tag but there are some problems with it. You can not use any of doubleOnchange, doubleOnClick,doubleOndblclick etc till now. It is one of the known issues and can be resolved in the next release.
Solution:
Here is the solution to achieve double select full functionality and avoid even know issues. But there is a trade off you have to forget Ajax in that solution means here both list will be populated when page will load. Then you can you use this javascript to acheive the desired effect.

var appsTemp = document.campaign_form.eve;
appsRedirect(0);
function appsRedirect(x) {
var selected = false;
for (m = appsTemp.options.length - 1; m >= 0; m--) {
appsTemp.options[m] = null;
}

for (i = 0; i <> 0) && (! selected)) {
appsTemp.options[0].selected = true;
}
}