You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Felipe Leme <ja...@felipeal.net> on 2004/03/09 13:52:57 UTC
Re: string taglib
On Tue, 2004-03-09 at 04:50, Henri Yandell wrote:
> I've been thinking recently that a new version of the String taglib is
> needed, implemented entirely as a set of EL-functions.
I agree that EL support is a must. Not only for String, but for all
supported taglibs (like mailer, for instance). So, we need a generic
framework to help that task (I'm working on it, but it will take a while
until the idea is mature enough to be sent to the list)
> Those that are already handled would be removed.
Agree. For instance, the random tags. Besides being handled by another
taglib (Random), they are based on Commnons Lang random classes, that
have some complex syntax in some cases.
> It's a vague todo
> [random(6 months) eta] for me at the moment.
Don't worry about time - just the fact of having these discussions is
already a progress for the project's current status :-).
Maybe a next step would be defining an execution plan for the whole
project. Something like this:
1.Finish migration to ASF 2.0 license
2.Create the new Legacy category and re-classify existing taglibs
3.Fix existing bugs
4.Release new bug-fix releases
5.Migrate to the new EL-support schema
6.Release a minor/major release that supports EL and RT
Of course, some of these tasks could be done in parallel (for instance,
fixing bugs and planning the LE support).
> > I saw someone mention that the string taglib should also be called
> > "Legacy".
It might have me, but if so, it was a mistake.
> This taglib however contains a lot of functionality that isn't
> > provided by JSTL and I'd very much like to see it kept in...
I agree. There might be some functionality provided by JSTL 1.1
functions, but that's not enough for 2 reasons:
- string currently has more tags than what's provided by JSTL 1.1
functions
- EL functions are only available on 2.0 and it will take a while for it
to be default and 1.2 be considered "legacy"
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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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
Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by 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: string taglib
Posted by Felipe Leme <ja...@felipeal.net>.
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
Re: string taglib
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 9 Mar 2004, Felipe Leme wrote:
> On Tue, 2004-03-09 at 04:50, Henri Yandell wrote:
> > I've been thinking recently that a new version of the String taglib is
> > needed, implemented entirely as a set of EL-functions.
>
> I agree that EL support is a must. Not only for String, but for all
> supported taglibs (like mailer, for instance). So, we need a generic
> framework to help that task (I'm working on it, but it will take a while
> until the idea is mature enough to be sent to the list)
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.
> > Those that are already handled would be removed.
>
> Agree. For instance, the random tags. Besides being handled by another
> taglib (Random), they are based on Commnons Lang random classes, that
> have some complex syntax in some cases.
Don't agree. :) I mean the ones that the JSP 2.0 function taglib already
covers, like capitalize.
> > It's a vague todo
> > [random(6 months) eta] for me at the moment.
>
> Don't worry about time - just the fact of having these discussions is
> already a progress for the project's current status :-).
>
> Maybe a next step would be defining an execution plan for the whole
> project. Something like this:
>
> 1.Finish migration to ASF 2.0 license
> 2.Create the new Legacy category and re-classify existing taglibs
> 3.Fix existing bugs
> 4.Release new bug-fix releases
> 5.Migrate to the new EL-support schema
> 6.Release a minor/major release that supports EL and RT
I'd kill 5 and 6 and replace them with:
5. Migrate undeprecated tags from Legacy taglibs into the Unstandard
taglib.
6. Release JSP 2.0 versions of taglibs.
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.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org