Alexander, This makes sense. I am thinking then with the changes in the TLD, plus the significant increases in functionality inside the TLDs it may make sense to go ahead and call this Taglib 2.0 and try to do a clean break.
One option would be to keep the 1.0 version of the tag lib in the deployment as well, as I believe this is the most commonly used, however this may just prolong the problem. Perhaps it would make sense to create a documentation page specific to this upgrade which contains the errors users are likely to see and instructions on how to upgrade to the latest version of the tag lib. At this point, most of the functionality for the new taglibs is complete, the only major remaining piece is the new include content functionality which was requested in this ticket: https://issues.apache.org/jira/browse/SLING-2834 -Dan On 6/13/13 9:15 AM, "Alexander Klimetschek" <[email protected]> wrote: >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
