Wednesday, 6 February 2013

Views | J2EE Tutorial pdf

Views

In this chapter, we examine the View component of the Struts framework. Some of the topics that we discuss are using tags from Struts tag libraries, using ActionForms, and deploying Views to a Struts application.
The goal of this chapter is to give an understanding of the Struts View and the components that can be leveraged to construct the View.

Building a Struts View

The Struts View is represented by a combination of JSPs, custom tag libraries, and optional ActionForm objects. In the sections that follow, we examine each of these components and how they can be leveraged.
At this point, we should have a pretty good understanding of what JSPs are and how they can be used. We can now focus on how JSPs are leveraged in a Struts application.
JSPs in the Struts framework serve two main functions. The first of these functions is to act as the presentation layer of a previously executed Controller Action. This is most often accomplished using a set of custom tags that are focused around iterating and retrieving data forwarded to the target JSP by the Controller Action. This type of View is not Struts-specific, and does not warrant special attention.
The second of these functions, which is very much Struts-specific, is to gather data that is equired to perform a particular Controller Action. This is done most often with a combination of tag libraries and ActionForm objects.

Deploying JSPs to a Struts Application

Before we can begin looking at the role of a JSP in the Struts framework, we must take a look at how JSPs are deployed to the framework. JSPs are most often the target of a previous request; whether they are gathering or presenting data usually makes no difference as to how they are deployed. All JSPs should be deployed to a Struts application by using a <forward> element.
This element is used to define the targets of Struts Actions, as shown in the following code snippet:
<forward name="login" path="/login.jsp"/>
In this example, the <forward> element defines a View named login with a path of /login.jsp.
To make this <forward> element available to a Struts application, we must nest it within one of two possible Struts elements. We can make a JSP available globally to the entire application.
This type of JSP deployment is useful for error pages and login pages. We perform this type of deployment by adding the JSP to the <global-forwards> section of the struts-config.xml file. An example of this is shown in the following code snippet:
<global-forwards>
<forward name="login" path="/login.jsp"/>
</global-forwards>
The previous <forward> element states that /login.jsp will be the target of all Struts Actions that return an ActionForward instance with the name login, as shown here:
return (mapping.findForward("login"));

Note The only time that a global forward is not used is when an <action> element has a <forward> declaration with the same name. In this instance, the <action> element’s <forward> will take precedence. The second type of <forward> declaration is defined as an Action <forward>. These types of <forward> elements are defined as subelements of an <action> definition, and are accessible only from within that <action>. 
The following code snippet shows an example of this type of <forward> declaration:
<action path="/Login"
type="com.wiley.LoginAction"
validate="true"
input="/login.jsp"
name="loginForm"
scope="request" >
<forward name="success" path="/employeeList.jsp"/>
<forward name="failure" path="/login.jsp"/>
</action>
This <forward> definition states that /login.jsp will be the target of com.wiley.LoginAction when this Action returns an ActionForward instance with the name “failure”, as shown here:
return (mapping.findForward("failure"));

JSPs that Gather Data

Now that we know how JSPs are deployed in a Struts application, let’s take a look at one of the two most common uses of a JSP in a Struts application: using JSPs to gather data.
There are several methods that can be leveraged when gathering data using a JSP. The most common of these methods includes using the HTML <form> element and any combination of <input> subelements to build a form. While Struts uses this exact methodology, it does so with a set of JSP custom tags that emulate the HTML <form> and <input> elements, but also includes special Struts functionality. The following code snippet contains a JSP that uses the Struts tags to gather data:
<html:form action="/Login"
name="loginForm"
type="com.wiley.LoginForm" >
<table width="45%" border="0">
<tr>
<td>Username:</td>
<td><html:text property="username" /></td>
</tr>
<tr>
<td>Password:</td>
<td><html:password property="password" /></td>
</tr>
<tr>
<td colspan="2" align="center"><html:submit /></td>
</tr>
</table>
</html:form>
If we break this JSP into logical sections, we will first take notice of the four Struts HTML tags:
<html:form />, <html:text />, <html:password />, and <html:submit />. These tags include special Struts functionality that is used to gather HTML form data. We look at each of these tags in the sections that follow.
Note The Struts library that includes the HTML tags listed in our JSP is named the HTML Tag Library. It includes tags that closely mimic the same functionality common to HTML form elements.
The <html:form /> Tag
The first of these tags is the <html:form /> tag. This tag serves as the container for all other Struts HTML input tags. It renders an HTML <form> element, containing all of the child elements associated with this HTML form. While the <html:form /> tag does serve as an HTML input container, it is also used to store and retrieve the data members of the named ActionForm bean. This tag, with its children, encapsulates the presentation layer of Struts form processing. 
The form tag attributes used in this example are :-
action :- Represents the URL to which this form will be submitted. This attribute is also used to find the appropriate ActionMapping in the Struts configuration file, which we describe later in this section. The value used in our example is /Login, which will map to an ActionMapping with a path attribute equal to /Login.
name :- Identifies the key that the ActionForm that we will be using in this request to identify the FormBean associated with this Form. We use the value loginForm. ActionForms are described in the following section .
type:- Provides the fully qualified class name of the ActionForm bean used in this request. For this example, we use the value com.wiley.LoginForm, which is described following.

ActionForm Beans

Before we can move on to examining the rest of this form, we must discuss the org.apache.struts.action.ActionForm object. ActionForms are JavaBeans that are used to encapsulate and validate the request parameters submitted by an HTTP request. A sample ActionForm, named LoginForm, is listed in the following code snippet:
package com.wiley;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionError;
public class LoginForm extends ActionForm {
private String password = null;
private String username = null;
public String getPassword() {
return (this.password);
}
public void setPassword(String password) {
this.password = password;
}
public String getUsername() {
return (this.username);
}
public void setUsername(String username) {
this.username = username;
}
public void reset(ActionMapping mapping,
HttpServletRequest request) {
this.password = null;
this.username = null;
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if ( (username == null ) || (username.length() == 0) ) {
errors.add("username",
new ActionError("errors.username.required"));
}
if ( (password == null ) || (password.length() == 0) ) {
errors.add("password",
new ActionError("errors.password.required"));
}
return errors;
}
}
As we look over this class, we should first notice that it extends the org.apache.struts.action.ActionForm class; all ActionForm beans must extend this class. After this, we will notice that the LoginForm definition itself contains two data members--username and password--as well as six methods.
The first four of these methods are simple setters and getters used to access and modify the two data members. Each of these setter methods is called by the Struts framework when a request is submitted with a parameter matching the data member’s name. This is accomplished using JavaBean reflection; therefore, the accessors of the ActionForm must follow the JavaBean standard naming convention. In the next section, we learn how these data members are mapped to request parameters.
The last two methods of this ActionForm are probably the most important. These methods are defined by the ActionForm object, and are used to perform request-time processing.
The reset() method is called by the Struts framework with each request that uses the defined ActionForm. The purpose of this method is to reset all of the LoginForm’s data members prior to the new request values being set. We should implement this method to reset our form’s data members to their original values; otherwise, the default implementation will do nothing. As we look over our reset() method, we will note that it sets both of our data members back to null. This method guarantees that our data members are not holding stale data. The last method defined by our LoginForm is validate(). This method should be overridden when we are interested in testing the validity of the submitted data prior to the invocation of the Action.execute() method. The proper use of this method is to test the values of the data members, which have been set to the
matching request parameters. If there are no problems with the submitted values, then the validate() method should return null or an empty ActionErrors object, and the execution of the request will continue with normal operation. If the values of the data members are invalid, then it should create a collection of ActionErrors containing an ActionError object for each invalid parameter and then return this ActionErrors instance to the Controller. If the Controller receives a valid ActionErrors collection, it will forward the request to the path identified by the <action>element’s input attribute. If our ActionForm does not implement the validate() method, then the default implementation will simply return null, and processing will continue normally.
After looking at the LoginForm’s validate() method, we will see that the request using this ActionForm must contain a username and password that is not null or a 0 length string.

The Input Tags

Once we get past the attributes of this instance of the <html:form /> tag, we will see that it also acts as a parent to three other HTML tags. These tags are synonymous with the HTML input elements.
The <html:text /> Tag
The first of the HTML input tags is the <html:text /> tag. This tag is equivalent to the HTML text input tag, with the only difference being the property attribute, which names a unique data member found in the ActionForm bean class named by the form’s type attribute. The following code snippet contains our <html:text /> tag.
<html:text property="username" />
As we can see, the property attribute of this instance is set to the value username; therefore, when the form is submitted, the value of this input tag will be stored in the LoginForm’s username data member.
The <html:password /> Tag
The second of the HTML tags is the <html:password /> tag. This tag is equivalent to the HTML password input tag. It functions in the same way as <html:text />; the only difference is that its value is not displayed to the client. The following code snippet contains our <html:password /> tag:
<html:password property="password" />
As we can see, the property attribute of this instance is set to the value password, which results in the LoginForm’s password data member being set to the value of this input parameter.
The <html:submit />Tag
The last HTML tag that we use is the <html:submit /> tag. This tag simply emulates an HTML submit button by submitting the request to the targeted action:
<html:submit />
The Steps of a Struts Form Submission
When a View containing this type of <html:form /> is requested, it will be evaluated and the resulting HTML will look similar to this:
<form name="loginForm"method="POST" action="/employees/Login.do">
<table width="45%" border="0">
<tr>
<td>User Name:</td>
<td>
<input type="text"
name="username"
value=""></td>
</tr>
<tr>
<td>Password:</td>
<td>
<input type="password"
name="password"
value=""></td>
</tr>
<tr>
<td colspan="2" align="center">
<input type="submit"
name="submit"
value="Submit"></td>
</tr>
</table>
</form>
Note As we examine the evaluated form, we will notice that the value of the <input> elements is an empty string. This will not always be the case. If the session already includes an instance of the ActionForm named by the <form> element's name attribute, then the values stored in its data members will be used to prepopulate the input values.
Once the user of this form has entered the appropriate values and clicked the Submit button, the following actions take place:
1.The Controller creates or retrieves (if it already exists) an instance of the com.wiley.LoginForm object, and stores the instance in the appropriate scope. The default scope is session. To change the scope of the ActionForm, we use the <html:form /> attribute scope.
2.The Controller then calls the com.wiley.LoginForm.reset() method to set the form’s data members back to their default values.
3. The Controller next populates the com.wiley.LoginForm username and password data members with the values of the <html:text /> and <html:password /> tags, respectively.
4.Once the data members of the com.wiley.LoginForm have been set, the Controller invokes the com.wiley.LoginForm.validate() method.
5.If the validate() method does not encounter problems with the data, then the Action referenced by the <html:form />’s action attribute is invoked and passes a reference to the populated ActionForm. Processing then continues normally.
That’s about it. There is almost no limit to the type of Views that can exist in a Struts application, but this typeof View is most tightly bound to the Struts framework.

No comments: