Steve Bang wrote: > > According to the JSP 1.1 specs, the description of the <taglib-uri> setting > can be a short name. In both the Sun spec and in WebLogic docs, they give > examples of using short names, such as "myPRlibrary" (in the JSP 1.1 specs) > and "myTLD" (in WebLogic docs). And, Hans uses "/orataglibs" (or something > similar) for the tags in his book. Sometimes, shortened names have a > forward-slash in front of them, other times they don't. And, yes, I've read > the specs and the errata, and Hans' book. What I'm surprised at is the > amount of disagreement, or at least confusion. I'm finding about the right > approach is on such a seemingly simple topic. A taglib URI can be a URL > (such as, Jakarta's approach, > "http://jakarta.apache.org/taglibs/<tagLibName>") or a relative URL (I've > seen many using "/WEB-INF/tlds/<taglibname>.tld"), or even a short symbolic > name (like "TagLib").
Right. The uri attribute may be either a symbolic name (a short name or a full URL, for instance) or a path to the location of the TLD file (or a JAR file containing the TLD). If you use a symbolic name, it must be unique within the application and you must map it to the real location with a <taglib> element in the application deployment descriptor (web.xml). Why does the spec support two different types of values for the attribute (i.e. symbolic name or path)? The thinking was that during development it may be easier to just use a path to the TLD, while a symbolic name would be more appropriate for deployment (e.g. allow you to change the location or name of the TLD/JAR file in one place, for instance when you upgrade the library). > But, here's what I don't get -- most of the time, > when a URL is used, it doesn't actually point to any file at the specified > address. Instead, it's only purpose seems to be as a way to help guarantee > a unique name -- it really doesn't matter what it is (it's only the unique > combination of characters that matter). Right again. A symbolic name can be any string, as long as it is unique within the application. In other words, if a URL format is used, it doesn't *have* to be a URL that actually points to anything. The idea, though, was that it should be a real URL to a page that described the tag library. It would serve as an easy way for a developer to find the documentation for the library, even though the container couldn't care less if the URL was real or not. > So, if this is the real purpose, as > a way to create a unique name -- essentially a symbolic name, then a > shortened name makes more sense to me, if it seems to be unique. I agree, which is why I always use just a short symbolic name. A new feature in JSP 1.2 is "auto-discovery" of tag libraries. This means that you no longer have to define a mapping between the symbolic name and the actual location in the web.xml file. Instead, the container finds all TLD files (even within JAR files) when the application starts and creates an implicit mapping from the symbolic name for the library (defined by the <uri> element in the TLD) and the location. In your JSP pages, you just use the symbolic name defined for the library as the taglib directive's uri attribute. For more about this, see: <http://www.onjava.com/pub/a/onjava/2001/10/10/jsp.html> This makes it a bit more important to define a globally unique URI for the library, though. One way is to use a short name that includes the DNS name for the company or organization, the same way as is recommended for Java package names. An example would be "com.ora/taglib". Still, a name that is reasonably unique, but not guaranteed to be unique, works as well. If you're unfortunate enough to use two tag libraries that have the same default URI, you can define a new unique URI for one of them with the <taglib> element in the web.xml file. > The "URL > (but not actually a real URL)" approach is clever in some regards, but > introduces misconceptions to naive users about what it represents. Today, > someone at work told me that they thought that if he was using a laptop that > wasn't connected to the Internet, they wouldn't be able to access this file, > so therefore they thought the taglib directive would fail. Yes, that's an unfortunate misunderstanding. > As a result, I'm > arguing that a symbolic name that is unique, such as myUniqueNameTLD or > something like that, is possibly the best approach. I've even joked that > using a URL (with your company name in it) may be more likely a problem than > a short name (and less flexible) in that a company might get acquired, and > the acquiring company could end up insisting that the URI be changed. > > So, I'm interested in hearing some opinions about why the URL approach won > in your designs -- was it just that it seemed what everyone else was doing? > Or, do some application servers cannot handle shortnames? Or, why did you > pick a shortname -- weren't you worried about the uniqueness issue? Even though I always use short symbolic names, I believe the reason for using a URL sometimes stem from the fact that the JSP 1.1 spec used URLs in some examples, and even recommended it I believe. Any compliant container should handle all types of uri attribute values, though. If not, it's a bug. Another reason may be the misconception that the URI *must* be globally unique, and using a real URL can guarantee that. I hope this sheds some light on the issue. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
