TLD files may be placed in WEB-INF or any subdirectory of WEB-INF.
© Copyright Marcus Green 2007
6.6) Configure the deployment descriptor to declare one or more tag libraries, deactivate the evaluation language, and deactivate the scripting language.
Custom tags are extensions to the JSP language in that they allow a programmer to define new features that can be used in a similar way to the built in JSP tags. Custom tags are distributed in the form of a custom tag library (typically in a jar file). Custom tags offer additional re-usable objects in a similar way to JavaBeans. They contribute towards the goal of separating the business logic from the presentation logic.
There are a wide range of “off the shelf” custom tags available in the form of the JSTL or Java Server Pages Standard Tag library, that would probably cover most functionality you would require, but for the purpose of the exam you need to know how to create and deploy your own custom tags. To read more about the JSTL go to
http://java.sun.com/products/jsp/jstl/
The JSTL is shipped by default with Tomcat5 but is hidden in
\webapps\jsp-examples\WEB-INF\lib
It takes the form of two jar files
jstl.jar and standard.jar
To make the JSTL available to your web application copy these jar file to the WEB-INF\lib directory of your application.
The syntax of using a custom tag is very similar to that of a JSP action, except that instead of the JSP action prefix of jsp, a custom tag uses a prefix attribute of the taglib directive used to instantiate the group of custom tags. Thus the standard prefix for using the core JSTL taglibs is simply the letter c and the following code shows a trivial use of forEach tag.
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<html>
<head>
<title>Counting example using JSTL 99</title>
</head>
<body>
<c:forEach var="i" begin="1" end="5">
<c:out value="${i}" />
<br/>
</c:forEach>
</body>
</html>
<html>
<head>
<title>Counting example using JSTL</title>
</head>
<body>
<c:forEach var="i" begin="1" end="5">
<c:out value="${i}" />
<br />
</c:forEach>
</body>
</html>Don't worry about the details of how this works (it uses the Expression Language instead of scriptlets), just note how the tags with the c prefix work in a very similar way to the standard JSP tags. If your setup works, when you access the page with your browser you should see a count of one to five.
There are two types of custom tag, the classic tag and the Simple tag introduced with JSP2. SimpleTags are far easier to write than classic, but for the purpose of the exam you need to know about both type of tag. For the purpose of explaining how tags are configured I will illustrate with a very simple tag that simply prints out the string “Hello World” to the output stream.
package com.examulator;
import java.io.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
public class TagDemo extends SimpleTagSupport {
public void doTag() throws JspException, IOException {
JspWriter out = getJspContext().getOut();
out.write("Hello, world.");
}
} Compile this class and place it in the directory
WEB-INF\classes\com\examulator
Now the tag is in place you need to inform the JSP container about the location and details of the tag.
The jsp container is informed about the JSTL core tag with the uri as
"http://java.sun.com/jstl/core_rt"
Because the JSTL jar files are in the WEB-INF\lib directory they are added to the class path of the container and thus it finds the tag-class that matches the forEach name.
For the TagDemo tag I will show two ways of informing the container about the tag. The one is more obvious and intuitive, the other is the slightly more complex but recommended way. Every custom tag must have a matching Tag Library Descriptor file or TLD. When you use a tag that has been wrapped up in a jar file the tld is hidden. (if you unzip the jars for the JSTL you would find its tldfiles). A tld file is an XML file that tells the JSP container about the tag and is quite similar to a deployment descriptor (web.xml). The tld for the TadDemo is as follows
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag
Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-
jsptaglibrary_1_1.dtd"> <taglib> <tlibversion>1.0</tlibversion> <jspversion>1.1</jspversion> <shortname>TagDemo</shortname> <uri>http://www.mycompany.com/taglib</uri> <info>An example tag library</info> <tag> <name>TagDemo</name> <tagclass>com.examulator.TagDemo</tagclass> <body-content>empty</body-content> <info>Just Says Hello</info> </tag> </taglib>
|
|
TLD files may be placed in WEB-INF or any subdirectory of WEB-INF. |
Save this file with the name TagDemo.tld in the WEB-INF directory of your application. *. tld files must be stored either in the WEB-INF directory or any directory under the WEB-INF directory. You might get a question on the exam that asks if they must be stored in WEB-INF/tlds or some other location.
The syntax for the taglib directive is given in the specification as
<%@ taglib ( uri=”tagLibraryURI” | tagdir=”tagDir” ) prefix=”tagPrefix” %>
Thus you can use uri to refer to the deployment descriptor or you can use tagdir to refer directly to a tld file. The uri approach is generally preferred for its flexibility but the tagdir approach can be handy for a quick and dirty development task.
Create a jsp file at the root of your application with the following code.
<%@ taglib uri="WEB-INF/TagDemo.tld" prefix="h"%> <html> <head> <h:TagDemo/> </body> </html>
When you request this page it should generate the output
Hello, World
Note how the first line tells the page where to find the taglib by giving the uri of the tld file and it sets the prefix for the taglib. The prefix can be an arbitrary letter or collection of letters, but it is best to avoid the well known prefixes of the JSTL such as the letter c, and you are not allowed to use the reserved prefixes of
The objective for this topic asks “Configure the deployment descriptor to declare one or more tag libraries”
And the final way of informing the container about tag lib will involve modifying the deployment descriptor. Add the following text underneath the web-app tag in your deployment descriptor (WEB.XML)
<jsp-config>
<taglib>
<taglib-uri>
www.examulator.com
</taglib-uri>
<taglib-location>
/WEB-INF/TagDemo.tld
</taglib-location>
</taglib>
</jsp-config>
Now change the first line in the jsp to read
<%@ taglib uri="www.examulator.com" prefix="h" %>
Note how the setup now has three levels of indirection, the uri in the JSP page points to the matching entry in the deployment descriptor, the deployment descriptor entry points to the tld file and the tld file points to the actual Java class.
The javax.servlet.jsp.tagext.BodyTagSupport allows the creation of custom tags where the body of the tag (the content or parameters between the opening and closing tags) can be accessed and processed. It is a child of javax.servlet.jsp.tagext.TagSupport and it thus allows the creation of “classic tags” which are slightly more complex than those created using the SimpleTagSupport interface.
The expression language capability is so useful you might ask why you would want to disable it. It could be that you are maintaining code that would cause some conflict with the EL tags, e.g. If you had some templating text that used the curly braces {}.
Add the following in web.xml under the web-app tag to disable the EL.
<jsp-config>
<jsp-property-group>
<display-name>Ignore EL</display-name>
<url-pattern>*.jsp</url-pattern>
<el-ignored>true</el-ignored>
</jsp-property-group>
</jsp-config>If you want to disable EL processing in an individual jsp page you can include the following in the page.
<%@ page isELIgnored="true"%>
Note that disabling within the page will take priority over disabling within the deployment descriptor (WEB.XML), i.e. If el-ignored was set to true in WEB.XML but isELIgnored was true in the jsp, that page would not process any el code. Note the inconsistent naming between the WEB.XML tag and the page directive. In the page it is isELIgnored, but in the WEB-XML it is el-ignored (note the missing is).
The scripting language can be deactivated with the following tags in the deployment descriptor
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>If you deactivate the scripting language in the deployment descriptor, it doesn't just pass through any script untranslated it will generate an error when you attempt compilation.
Other sources
Suns Tutorial on Tag libraries
http://java.sun.com/products/jsp/tutorial/TagLibrariesTOC.html
O'Reilly's On Java, JSP Deployment
Descriptor News section
http://www.onjava.com/pub/a/onjava/2003/12/03/JSP2part2.html
This objective according to Mikalai Zaikin
http://java.boot.by/wcd-guide/ch06s06.html