Whatever we do, we should try to be as compatible as possible - so if people don't have huge include hierarchies with duplicate taglib imports, updating to a newer taglib bundle should work without any changes. In fact, I could argue that the duplicate imports are the problem - if there is a global jsp with the import why do it again? But I think it's not worth going down this road.
So, let's use a version neutral uri for the future, leave the old ones for compatibility and use the next logical version for the new taglib - either 1.x or 2.0, depending on how compatible this is. Starting with 1.0 would work as well, but I like to still see the evolution of the api in the version. Carsten 2013/6/13 Dan Klco <[email protected]> > 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 > > -- Carsten Ziegeler [email protected]
