jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karr, David" <David.K...@wamu.net>
Subject RE: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Date Wed, 10 Mar 2004 16:42:56 GMT
In my opinion, a good way to provide an EL-ized tag library in the
transition between JSP 1.2 and JSP 2.0, while minimizing the conflict
from normal development of the library, is to keep the EL-ization out of
the normal tag library, and build a second tag library of "shells" that
all inherit from the tags in the base library, whose only purpose is to
pass the attribute values through the EL engine.

The advantage of implementing "separation of concerns" here is that once
JSP 2.0 is generally available, you can simply replace use of the EL
library with the standard library ("standard" just means the base
library, not the JSTL).

The slight difficulty in maintaining a separate EL library is that you
have to continually  (or just near a release) track changes to the
interface of the base library.  This is mitigated by the fact that all
of the code in the EL library is very simple and boilerplate-like.  It
is quite easy to run occasional diffs of the standard and EL TLD file to
detect new changes, and do simple cut/pastes in the EL code to implement
changes.

In fact, the simplicity of the code in the EL library makes it
concievable that the EL library could be code-generated.  This might be
worthwhile if you expect the standard library to undergo many interface
changes before JSP 2.0.

Except for the code generation, this is exactly what I did in Struts-EL
(although it probably looks like it was code-generated).  When I notice
that someone has committed a change to one of the XML files that we use
to generate the TLD (and it isn't just a doc change), then I view the
TLD diffs and do some simple copying in two source files (two files for
each tag), and I'm done.  You can inspect the code in CVS to see how
it's done.

-----Original Message-----
From: Henri Yandell [mailto:bayard@generationjava.com] 
Sent: Wednesday, March 10, 2004 5:53 AM
To: Tag Libraries Developers List
Subject: Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)



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


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