JavaBeans

Using beans makes working with JSPs easier for all levels of programmers.
Using the Bean

Now that we have created our simple bean class, how do we use it from within a JSP? JSPs recognize three special tags, all of which begin with “jsp:”.

Before we continue, a word of warning: the special tags that allow us to work with JavaBeans from within a JSP are written in XML rather than HTML. While HTML is a loosely defined specification that does not always require us to close a tag, XML is much stricter. Every opening <tag> must be closed by a matching </tag>. Without a closing </tag>, the XML parser will exit with an error. A tag can close itself by placing a slash at the end of the tag, as in <tag/>.

This means that within an HTML-generating JSP using JavaBeans, you will have to keep track of two slightly different syntaxes. After a while, you will find that moving between these two syntaxes is almost second nature. Moreover, the JSP parser produces error messages that make it relatively easy to determine when you have forgotten to place a trailing slash on a JavaBean tag. However, this mix of syntaxes can be maddening at the beginning, and you can expect to go through some hardship in learning to understand it.

To use a JavaBean class, we use the special <jsp:useBean/> tag. This tag tells the JSP to find and load a particular bean and to create an instance of the bean within our JSP. The <jsp:useBean/> tag also lets us give our bean instance a name that we will use later on. Here is an example of how to load our SimpleBean class from within a JSP:

<jsp:useBean id="simple"
 class="il.co.lerner.SimpleBean"/>

As you can see, the tag ends with a slash (/), following the XML syntax. There are actually cases in which you might prefer to separate the <jsp:useBean/> tag into an opening <jsp:useBean> and closing </jsp:useBean>; whatever is between those two tags is only performed when the bean is first loaded into memory. However, the simpler form is not uncommon.

The <jsp:useBean/> tag takes two mandatory parameters. The class parameter names the package and class in which our bean sits. The id parameter gives our bean a unique name within the JSP. As with variable names, it is a good idea to choose clear identifiers for working with beans. The more obvious the name, the easier it will be to debug our JSP later on.

We can set and retrieve property values within our bean instance with the <jsp:setProperty/> and <jsp:getProperty/> tags. Both of these tags take a name parameter whose value should be identical to the id that we gave our bean earlier on (I am sure there is a good reason why we use an id attribute in <jsp:useBean/> and a name attribute in <jsp:setProperty/>, but I find it to be confusing). We can thus retrieve the value of the userID property with the following tag:

<jsp:getProperty name="simple" property="userID"/>

This retrieves the userID property from the simple bean and places it inside of the JSP. Note that this does not simply retrieve the value, it also makes it visible to the user. Also notice that the capitalization of our property name has been altered slightly. In order to access the getUserID method within our bean, we use <jsp:getProperty/> for the property userID. Don't be fooled into thinking the property names are case-insensitive, however; this transformation takes place simply to keep things readable.

To modify the value of a property, we use the <jsp:setProperty/> tag. This tag does not return any results, but it does take a value attribute whose value is then handed to the appropriate method in the bean class:

<jsp:setProperty name="simple" property="userID"
 value="300"/>

Listing 2 contains a complete JSP that demonstrates how we can use our SimpleBean class from within a JSP. It displays the default value of the userID property, then sets that property to a new value and displays the new value.

Listing 2. use-simple.jsp

Parameters and Properties

It is certainly common for properties to be stored in a bean's instance variables, as in our SimpleBean class. In such cases, invoking <jsp:setProperty/> effectively sets the value of the field, and invoking <jsp:getProperty/> retrieves its current value. Of course, there is no reason why properties must reflect fields. Properties can easily be stored to and retrieved from a relational database. When you retrieve a property, it is possible the returned value is being calculated in real time rather than being returned from an instance variable.

Consider, for example, how we might create a bean that performs simple mathematical operations. We can set two read/write properties (call them arg1 and arg2) and then a number of read-only properties we can use to perform calculations on these arguments. Listing 3 (available at ftp.linuxjournal.com/pub/lj/listings/issue86) contains a simple bean, Calculate.java, which demonstrates how we can accomplish this.

Because there is no setSum property, the JSP engine will not allow us to invoke <jsp:setProperty/> on the sum property. However, it will allow us to set arg1 and arg2 and to retrieve each of the individual properties we might want.

Now that we have a working bean, we can use it from within a JSP. Listing 4 contains the listing for calculator.jsp, which performs some basic calculations using the JavaBean we just created.

Listing 4. calculator.jsp

The first and most interesting part of calculator.jsp is the way in which it sets the properties:

<jsp:setProperty name="calculator" property="*"/>

Normally, we can take one of the parameters passed via GET or POST and assign its value to a particular property using the following notation:

<jsp:setProperty name="calculator"
 parameter="foo" property="arg1"/>
In other words, the above tag will take the foo parameter and use its value when invoking setArg1 on the calculator bean. But when we use an asterisk, as in Listing 4, we indicate to the JSP engine that we want to take each of the parameters we received and assign each of the values to the properties of the same name. Thus, the arg1 parameter will be passed to the arg1 property and so forth.

On my system, where I have installed calculator.jsp under the examples/jsp URL, I can assign arg1 the value 5 and arg2 the value 20 with the following URL: http://localhost/examples/jsp/calculator.jsp?arg1=5&arg2=20.

Of course, this is not a foolproof system. I can cause a runtime exception by passing the following URL: http://localhost/examples/jsp/calculator.jsp?arg1=5&arg2=20.0.

The JSP engine tries to assign 20.0 (a float value) to arg2 (an int), which fails.

We can surround our <jsp:setProperty/> and <jsp:getProperty/> tags with scriptlet tags, using the standard Java try-and-catch mechanism to attempt to avoid runtime errors. For example, the following code ensures we will never have to deal with division-by-zero exceptions when using getQuotient:

<P>Quotient:
    <% try { %>
        <jsp:getProperty name="calculator"
        property="quotient"/>
    <% } catch (Exception e) { %>
        <B>Error! division by zero</B>
    <% } %>
</P>

At the same time, this sort of code introduces more Java into the JSP, precisely the reason why we began to use beans. Whether the nonprogrammers on your staff will be able to handle this sort of code depends very much on your environment, as well as the sorts of beans you have created.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

help !! Struck in java bean

Anonymous's picture

hi all
lets starts with my problem!!!!
i have created a javabean which stores the password and username.I have created a bean so that if an unauthenticated user types the URL of any other pages before going to login first he will be greeted with the message to login first.
But i m not be able to do this.
plz help
i have admin.jsp thats asks for username and password.then it is redirected to welcome.jsp.
but if an unauthenicated user types the url of welcome.jsp he must get the msg to login first.
also tell me if i m right in creating a bean for storing username and password.
Thanks

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState