This lab includes three exercises that should be relatively easy. The first two have to do with writing and using simple custom tags. The third exercise asks you to write a small JavaBean class. The last section of the lab is not really lab work -- it asks you to think further about the design of your term project.
You should hand in copies of the TLD and the Java source code files that you create for Parts 2 and 3. These are due in lab next Friday. I might run your server to check that you have done Part 1. (More likely, I will just trust you.) There is nothing to turn in for Part 4, but we will discuss it in class next week. You should think about Part 4 before class on Monday.
A small library of custom tags for working with logged-in users was presented in class. The tag library includes <u:user>, <u:ifuser>, <u:ifnouser>, and <u:getuser>. You can probably find a use for some of the tags in your term project. For example, you might find it convenient to have a simple way to put the user's name on the page. Or you might use <u:ifuser> on your main page to add some items that are not presented to "guest" users who have not logged in.
The first exercise of the lab is to deploy the tag library into your term project and test one of the tags on one of your pages. You will need two files: A jar file that contains the tag classes and a tld file that describes the tags. These files can be found in the directory /home/cs371/sample_files. You should:
Remember that to use one of the user tags on one of your pages, you must add a line such as
<%@ taglib prefix="u" uri="/WEB-INF/user.tld" %>
to the beginning of the JSP file. To test the <u:user> tag, just add it to a page that requires the user to log in. The tag will be replaced on the page by the user's name.
This part of the lab asks you to write a pair of custom tags. It's a fairly easy exercise because you will follow very closely the example of the user tags from Part 1. You will also learn to make a jar file. (If you have ideas for other tags that you would like to write instead, discuss it with me.)
In a few examples, in past labs, we have used the same JSP page to both show a form and to process the data from the form. The page needs a way of knowing which of these tasks it should do. The way to tell is to test whether one of the request parameters that represents the form data is null. If the parameter is null, the page should display the form. If it is non-null, it means that data has been received from the form, and it should be processed. It would be nice to be able to make the decision with JSP tags, to be able to say, for example:
<p:ifparam name="username">
.
. (process the data from the form)
.
</p:ifparam>
<p:ifnoparam name="username">
.
. (show the form)
.
</p:ifnoparam>
The <p:ifparam> tag would test whether the request parameter named "username" is non-null, and it would only output its body to the page in that case. The <p:ifnoparm> tag would do just the opposite. These tags require an attribute to specify the name of the parameter that is to be checked. The object of this part of the lab is to write ifparam and ifnoparam tags. To do this:
You should now be able to test your tags on a Web page. In fact, you don't really need an HTML form to do the test, since parameters can also be coded directly into a URL. For example, you can send a parameter named "user" with value "fred" to a page using a URL of the form
http://cslab7.hws.edu:8080/app/page.jsp?user=fredYou can use the parameter tags on that page to test whether a value has been supplied for the parameter named "user".
Tag libraries are usually deployed in jar files, not individual classes. If you would like to make a jar file for the tags you have created, just go to the classes directory (not the subdirectory -- you need to be in the main directory for the names of the files to be recorded correctly in the jar file), and give the command
jar cf params.jar ptags/*.class
where "params.jar" is the name you want to use for the jar file and "ptags" is the name of the subdirectory. Now, if you move params.jar into the lib directory and delete the class files, the tags should still work.
Note on compiling classes in packages: As you know, a Java file that belongs to a package should be in a subdirectory of the main directory. As a general rule, when you compile Java files that are in a package, you should be in the main directory, not the subdirectory, when you give the javac command. That is, you might compile the two Java files you have created by issuing the command
javac ptags/*.java
while in the classes directory. For the simple classes in this lab, it won't make any difference which directory you are in when you do the compilation, but it does make a difference in the case where files refer to other files in the same directory tree. If you are not in the main directory when you issue the compile command, the compiler will not be able to locate the necessary files. In fact, no matter what you are doing with packages, I suggest that you always stay in the main directory to avoid confusing yourself.
We have looked at JavaBeans in class, without ever using them in practice. You should have some experience with them, so let's write a simple JavaBean class.
In J2EE, beans are most often used to represent "entities" of some type. That is, a bean stores the data for some particular object, gathered conveniently in one place. The bean has "properties" representing the data stored in the bean. From outside the bean object, the properties are accessed with "get" and "set" methods. The one other rule is that the class that defines a bean must have a constructor that does not require parameters.
Try to think of a type of bean that will be useful in your term project. A typical example would be to represent a user by storing a user name together with other information about the user such as email address or preferences.
It is a good idea to put bean classes in a package, so create another subdirectory of the classes directory to hold bean classes. You might use beans or data as the name of the package, for example. Create the bean class in the subdirectory, and set the package name of the class to match. In the source code for the bean, add a private member variable for each property, and add "get" and "set" methods for each property. Compile the class.
Finally, you should test that the bean is available in your Web application. Remember that you can always use bean classes in your java code, in the same way that you would use any other class. However, there are a few JSP tags that are designed for working with beans. Recall that
<jsp:useBean id="userinfo" scope="session" class="beans.UserInfo"/>
will either fetch (if it already exists) or create (if it does not) a bean object belonging to the class beans.UserInfo. This bean is stored as an attribute in the session object, associated with the name "userinfo." You can set a property in this bean with a tag such as
<jsp:setProperty name="userinfo" property="email" value="fred@bedrock.org">
and you can retrieve a property value for display on the page with
<jsp:getProperty name="userinfo" property="email">
See if you can get these to work with your own bean class, and consider using beans to organize the data in your term project instead of using masses of individual variables.
This part of the lab is not really lab work. It is just to encourage you to think seriously about your overall web application project. Some things that I suggest you do:
Think about some "use cases" for people using your site. Trace through the sequence of interactions that a user will go through to perform each function that the web site provides. What pages will they see? What data will you need to manipulate? What data objects will you want to carry along throughout the interaction? What data needs to be stored persistently (in a database)? What errors can occur?
Based on your analysis, design the database tables that you will use to store the persistent data. Think about what bean classes might be useful to store data during an interaction. Design the look of your main page, with links to provide access to the functionality of your web application.
You will also want to think about security policy. Here is one typical approach: Make the main page of the site, and possibly some other features, visible to anyone. Possibly, the main page will show extra features to logged-in users. The part of the web site that is to be accessible only to users should be in a subdirectory (or several subdirectories if you want). You can configure a security constraint on this subdirectory to restrict access to logged-in users. You can also have an administrative subdirectory with access restricted to logged-in users who have been assigned to an "admin" role. (Probably, admin users should also have access to the general user directories.)
I suggest that you think about all this stuff, and that you discuss your ideas with me before you start the actual work of building the application.