Java Reference
In-Depth Information
When to Create Custom Tags
Does this seem like a lot of work to duplicate what can be done with already existing tags? Well, it's not as much work
as it may seem. Some of the work was set-up that will not have to be repeated (e.g., creating the tls folder and the tld
file). In addition, although the custom tag didn't save you, the programmer, any time, the number of tags needed in
the JSP was cut down substantially and will save the page designer time. Also, all those bean tags and parameters
are difficult for a non-programmer to understand and use; therefore the chance of error was greater and the time to
implement longer.
So, when should a custom tag be used? Obviously, if there are no tags to supply the needed function, a custom tag
is needed. If the amount of coding in the JSP, whether tags or scriptlets, is beyond the capability of the page designer,
the programmer should create a custom tag(s). Also, if the required function is needed in many pages, there are
two advantages to using the custom tag. One, the function is coded only once, in the tag handler class (i.e., the page
designer does not enter all the bean tags in multiple pages). Two, any changes to the function are made only once
in the tag handler class. If the bean tags needed to be modified, the designer would have to change every page that
contained the bean tags. So, the bottom line is that if a function is not available, used on many pages, or very complex,
a custom tag should be created.
In the above example, we short-stepped the custom tag implementation process. We specified the tag library and
path in the directive rather than defining a URI in the Web Deployment Descriptor and using the URI in the directive.
The advantage to using a URI is that if the tag library is moved or renamed, only the Web Deployment Descriptor needs
to be modified. If the actual path is specified in the directive, every page that uses that tag library has to be updated.
So, we will create a URI for the tag library. In addition, a new custom tag for a state drop-down menu will be
created. We will then create new JSPs to use the custom tag and show how a custom tag is easily reused and modified.
Finally, we will demonstrate how to pass information to a tag handler using a
tag attribute
.
Tutorial: Defining a URI
There are many types of deployment descriptors. Essentially, they all contain configuration information that the
server will need to deploy an application. The term “configuration information” covers a wide range of information
like security settings, data locations and, no coincidence here, tag library locations. The directory path and file that
a URI corresponds to is a great example of information “the sever will need to deploy the application” because
the application would not work if the deployment descriptor did not contain this information. As mentioned, the
advantage is that this is information is specified in one location (a file called web.xml) rather than in all the JSPs and
servlets. In RAD, you must create the deployment descriptor.
1.
In the Project Explorer, right-click the project TutorialsWeb and select Java EE then
Generate Deployment Descriptor Stub.
A file called web.xml will be created in the WebContent/WEB-INF folder. The file can be edited directly with a text
editor but there a more user friendly tool called the Deployment Descriptor Editor.
2.
Invoke the deployment descriptor editor by right clicking the web.xml file, select Open
With, then Web Application 3.0 Deployment Descriptor Editor.
3.
Initially the XML source code will be displayed. Change to the Design view by clicking the
Design Tab in the lower left corner of the pane (see Figure
11-2
).
