Dry your taglib URIs

by Bill Siggelkow

Related link: http://java.sun.com/products/jsp/tags/12/syntaxref1211.html#8780




It seems that despite the fact that JSP 1.2 has been out for quite a while; many developers are not aware of how to eliminate the annoying web.xml taglib directives using absolute URIs.

Personally, I've always been annoyed when I have
to create entries in the web.xml for the tag libraries and then essentially repeat myself by specifying a matching taglib directive on my JSPs. This always seemed to violate the DRY principle of software development. JSP 1.2 provides a nice solution to this problem by using absolute taglib URIs.


With JSP 1.2, a tag library’s absolute URI is specified in that library’s tag library descriptor (TLD) file. For example, here’s this declaration from the struts-bean.tld file:

<taglib>
<tlibversion>1.0</tlibversion>
<jspversion>1.1</jspversion>
<shortname>bean</shortname>
<uri>http://jakarta.apache.org/struts/tags-bean</uri>

Any JSP page that needs to use this tag library can reference it with the following page-level directive. The tag library does not need to be referenced in the web.xml file!

<%@ taglib
uri="http://jakarta.apache.org/struts/tags-bean"
prefix="bean" %>

Using this approach is convenient and easy; however, some developers frown on it. They feel that having the extra level of indirection is beneficial. If the taglib URI changes then you only need to change the web.xml. Yet, since a majority of my web development is with Struts, I almost never touch the web.xml file.


One way to work around this problem is to put all your taglib directives in a single JSP that you include throughout your application.


First, create a JSP file containing taglib directives that use the absolute URIs for the tag libraries you are using. The example below shows a JSP file containing the taglib declarations for the Struts bean, html, and logic tag libraries as well as the JSTL core and formatting tag libraries.


<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-logic" prefix="logic" %>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>

Then include this file at the top of your JSP pages using the include directive:


<%@ include file="/includes/taglibs.inc.jsp" %>


Since you are using the absolute URIs in the taglib directives, you are not required to enter a corresponding taglib element in the application’s web.xml file!


I have good success with this approach but YMMV -- I'd be interested in your experiences.


4 Comments

bazzargh
2004-06-22 10:59:00
There are some cons...
...mainly due to taglib developers who are not aware of this feature, eg sometimes the taglib jar doesn't even contain the tld. It's actually been there since JSP 1.1 - but back then it was only for a single tld called '/WEB-INF/taglib.tld'.


Another common issue is versioned uris in the tld's - this is what has happened in jakarta's taglibs project, eg:
http://jakarta.apache.org/taglibs/doc/input-doc/index.html


Since the URI used is for this taglib is 'http://jakarta.apache.org/taglibs/input-1.0', anyone using the web.xml-less method needs to change all their JSPs when the taglib version changes! (your include file tip helps with this, of course).

BillSiggelkow
2004-06-22 11:14:18
There are some cons...
Good point. Another issue I ran into when I first started using the absolute URIs was that some application server's didn't support them even though the server was *compliant* with JSP 1.2. Seems like I ran into this with an earlier version of Orion -- I am sure that it has been resolved by now.
tom_davies
2004-06-22 20:29:22
Check your page in IE
IE doesn't like the '<%@' sequence, even in an <pre> tag.
BillSiggelkow
2004-06-23 05:41:54
Check your page in IE
Thanks for catching that ... I have corrected it. I'll be more careful next time :)