Taglibs, EL and JSP 2.0 (was Re: string taglib)

[Martin Cooper <ma...@apache.org>]

(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

Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)

[Felipe Leme <ja...@felipeal.net>]

On Thu, 2004-03-11 at 02:21, Henri Yandell wrote:

> Sorry, have done. Sounds good to me. 

Ok, I will commit that then and ask you to test (the fix didn't quite
work for me, but I guess is a problem in my Linux/Tomcat setup - if I
run the same code standalone, it works).

> Unsure how to find your user in bugzilla to reassign over to you 

It's difficult sometimes, but in this case you could get it from my
comments (the user's key is the email address)

Felipe



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

Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)

[Henri Yandell <ba...@generationjava.com>]

> PS: by speaking of Strings, could you please take a look on bug 18964?
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=18964

Sorry, have done. Sounds good to me. Unsure how to find your user in
bugzilla to reassign over to you [really, really looking forward to
Commons and Taglibs moving to JIRA].

Hen


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

Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)

[Felipe Leme <ja...@felipeal.net>]

On Wed, 2004-03-10 at 10:53, Henri Yandell wrote:

> impossible given the size of the developer base. By the time we draw to a
> close, 2.0 will be becoming the standard.

Believe me, even it becomes the standard, many projects will still
depend on 1.2. Unfortunately, it takes time for some companies
(specially in the financial field) to approve new app servers version in
production. 

> 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

I agree - without such structure, it would be near impossible to do what
I propose. I will try to give it a shot later...


Felipe

PS: by speaking of Strings, could you please take a look on bug 18964?

http://issues.apache.org/bugzilla/show_bug.cgi?id=18964


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

Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)

[Henri Yandell <ba...@generationjava.com>]

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