Hi,
Sling's JSP taglib currently encodes the version in the URI:
http://sling.apache.org/taglibs/sling/1.0
http://sling.apache.org/taglibs/sling/1.1
http://sling.apache.org/taglibs/sling/1.2
http://sling.apache.org/taglibs/sling/1.3 (in the works)
This version is kept in sync with the <tlib-version>.
This is problematic, as upon upgrades you need to:
a) update the sling taglib bundle in your application
b) update *all* usages in JSPs to use the new URI
And if due to some more complex JSP include structures you have multiple taglib
inclusions:
included.jsp:
<%@taglib prefix="sling" uri="http://sling.apache.org/taglibs/sling/1.0"; %>
app.jsp (includes included.jsp directly or indirectly):
<%@taglib prefix="sling" uri="http://sling.apache.org/taglibs/sling/1.2"; %>
the JSP compiler will *throw* and your code break, since the uris are not equal.
Best practice as shown by the standard taglibs is not to include the version in
the URI:
http://java.sun.com/jsp/jstl/core
http://java.sun.com/jsp/jstl/xml
http://java.sun.com/jsp/jstl/fmt
http://java.sun.com/jsp/jstl/sql
http://java.sun.com/jsp/jstl/functions
This is similar to XML namespaces, where including versions in the namespace
URI is considered harmful as well.
So we should do the right thing and switch to something like
http://sling.apache.org/taglibs/sling
in a new sling taglib bundle release. Not sure what the <tlib-version> should
become, but it could start at 1.0 again, since AFAIU the separate URI makes it
a "new" taglib.
The only problem is that to do that step, existing application JSPs will have
to be changed once they want to update the bundle and could run into the
conflict mentioned above, if they don't or can't easily update all of them at
once. Say some framework has a "global.jsp" which should be updated, but
customer's usages of that, which re-define the taglib accidentally, are not
under control of the framework devs.
WDYT?
Cheers,
Alex
