Conventions and Other Issues
This section is not normative, although it reflects good design practices.
How to Define New Implicit Objects
We advocate the following style for the introduction of implicit objects:
Define a tag library.
Add an action called defineObjects; this action will define the desired objects.
Then the JSP page can make these objects available as follows:
<%@ tablig prefix="me" uri="......" %>
.... start using the objects....
This approach has the advantage of requiring no new machinery and of making very explicit
In some cases there may be some implementation dependency in making these objects
available; for example, they may be providing access to some functionality that only exists in
some implementation. This can be done by having the tag extension class test at run time for
the existence of some implementation dependent feature and raise a run time error (this, of
course, makes the page not J2EE compliant, but that is a different discussion).
This mechanism, together with the access to metadata information allows for vendors to
innovate within the standard.
Note: if a feature is added to a JSP specification, and a vendor also provides that feature
through its vendor specific mechanism, the standard mechanism, as indicated in the JSP
specification will win . This means that vendor specific mechanisms can slowly migrate
into the specification as they prove their usefulness.
Access to Vendor Specific information
If a vendor wants to associate with some tag library some information that is not described in
the current version of the TLD, it can do so by inserting the information in a document it
controls, inserting the document in the WEB INF portion of the JAR file where the Tab
Library resides, and using the standard Servlet 2.2 mechanisms to access that information.
The vendor can now use the ID machinery to refer to the element within the TLD.
JavaServer Pages 1.1 Specification
November 30, 1999