You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2013/06/13 15:15:01 UTC

Taglib URI versions considered harmful

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

Re: Taglib URI versions considered harmful

Posted by Alexander Klimetschek <ak...@adobe.com>.
On 13.06.2013, at 17:06, Carsten Ziegeler <cz...@apache.org> wrote:

> 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.

Right. Having two separate tld files, one with the old and one with the new URI, beneath using the same tag classes should work, hopefully.

Cheers,
Alex

Re: Taglib URI versions considered harmful

Posted by Carsten Ziegeler <cz...@apache.org>.
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 <da...@sixdimensions.com>

> 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" <ak...@adobe.com> 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
cziegeler@apache.org

Re: Taglib URI versions considered harmful

Posted by Dan Klco <da...@sixdimensions.com>.
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" <ak...@adobe.com> 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