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"). 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). 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. 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. 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?
>
> Steve
>
> ===========================================================================
Hi Steve,
I assumed (and this is just me guessing), that it had to do with
XML namespaces. ( http://www.w3.org/TR/1999/REC-xml-names-19990114/ )
This is how XML Namespaces are set, and jsp:getProperty or
custom:myAction are the same syntax used in XML to separate different
sets of elements (prefix:elementName). I'm assuming that the <% taglib
%> directive is JSP's way of identifying namespaces in any document,
given that most aren't going to be XML, and that containers parse jsp
pages as they would an XML doc, in which case, jsp: tags and then
custom: tags can be appropriately earmarked for the classes that run
them. Given that you want XML documents to be clear anywhere, using a
URI allows you to pick a reasonably unique identifier
(organization/department/project whatever) without having to consult the
rest of the world. Or perhaps they were just borrowing the idea of
namespaces and used the same syntax?
Anyway, that was my guess. Maybe someone who actually knows will
chime in now. :)
Josh
--
------------------------
Josh Partlow
[EMAIL PROTECTED]
===========================================================================
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
