jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Date Wed, 10 Mar 2004 13:53:26 GMT

To argue for the other view;

It seems pointless to spend the next year getting all the taglibs to 1.2,
which mainly means ELizing them, whilst also releasing 1.1 bugfixes and
starting work on 2.0 versions. Not so much pointless, but rather
impossible given the size of the developer base. By the time we draw to a
close, 2.0 will be becoming the standard.

If someone can come up with a build structure that, with minimal effort,
allows a 1.1, 1.2 or 2.0 version to be created, with 2.0 features blocked
from 1.1/1.2 and ELisation in the 1.2 version, all from the same source,
then it seems possible. Otherwise I'm in favour of merely providing
instructions on how to ELize a 1.1 library on the site and getting on with
a big rethink of taglibs for 2.0, in time to finish around about the point
2.0 gets more popular [1 year I'm estimating].

Hen

On Tue, 9 Mar 2004, Martin Cooper wrote:

> (Changing the subject, since we're now on a much more general subject that
> could impact many more taglibs than 'string'...)
>
> I agree with Felipe here that we can't (or at least shouldn't) punt on EL
> for JSP 1.2 and go straight to JSP 2.0. As far as I'm aware, there are no
> app servers available today that support JSP 2.0, and it will likely be a
> long time before Weblogic, WebSphere, et al, release products with such
> support. We can't ignore all of the developers who need to build apps on
> those platforms, and leave them stuck with only rtexprs until the app
> servers catch up to JSP 2.0.
>
> My own to-do list includes a Mailer 2.0 release that includes EL support
> for use on a JSP 1.2 platform. I'm thinking Mailer 1.x is for JSP 1.1,
> Mailer 2.x is for JSP 1.2, and Mailer 3.x is for JSP 2.0. Of course, we
> don't necessarily need to follow the same pattern for all of the taglibs
> here, that's just where my own thoughts are headed right now.
>
> --
> Martin Cooper
>
>
> On Tue, 9 Mar 2004, Felipe Leme wrote:
>
> > On Tue, 2004-03-09 at 10:06, Henri Yandell wrote:
> >
> > > I don't see any need to do anything for EL support. New versions of
> > > taglibs etc can be JSP 2.0 only in my opinion.
> >
> > I disagree. We cannot raise the bar to JSP 2.0 - it will take some time
> > (probably years) for that version be the standard in many projects in
> > the field.
> >
> > > 6. Release JSP 2.0 versions of taglibs.
> >
> > My idea is that the JSP 2.0 EL support would be transparent. Let's take
> > as example mailer. We would have:
> >
> > http://jakarta.apache.org/taglibs/mailer - this version would works on
> > JSP 1.1/1.2 (only with RT) support and JSP 2.0 (where EL is handled by
> > the container)
> >
> > http://jakarta.apache.org/taglibs/mailer-EL - that version should be
> > used only on 1.1 and 1.2 containers and it takes care of EL handling
> > (with no RT though)
> >
> > Note that the core code would be the shared - we would only have
> > differences on how to evaluate the EL parameters (similar to the
> > situation with have on JSTL 1.0)
> >
> >
> > That figure assumes the only difference between each JSP version is the
> > EL support. For the cases where there are more differences (like tags
> > being deprecated), we would have more taglibs:
> >
> > http://jakarta.apache.org/taglibs/strings
> > http://jakarta.apache.org/taglibs/strings-EL
> > http://jakarta.apache.org/taglibs/jsp2/strings
> >
> > In the particular case of Strings on JSP 2.0, maybe we should abolish it
> > completely and release a EL functions taglib instead.
> >
> > > I've no itch to come up with endless ways to support 1.1, 1.2 and 2.0 at
> > > the same time, increasingly complicating the tag development process.
> >
> > I agree it's a pain to support both, but as I mentioned before, we
> > cannot provide only 2.0 support. Maybe we could stop supporting 1.1
> > (although I've seen projects that depend on it, or even 1.0), but not
> > 1.2.
> >
> > In fact, if we come to a clever solution on how to handle/support these
> > multiple versions, that would be great for the project, because it would
> > be a model for many people (and other projects) to follow.
> >
> >
> > Felipe
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Mime
View raw message