On Tue, 23 Jul 2002, Niall Pemberton wrote:
> Date: Tue, 23 Jul 2002 03:28:22 +0100
> From: Niall Pemberton <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Status of Struts-EL contrib project
>
> David,
>
> >From your original post I assumed you were going to provide "JSTL" style
> struts tags by incorporating the "EL" functionality of JTSL (I read
> somewhere it was going to be split out from the JSTL, perhaps to commons)
> with the main aim being that struts developers could use them now (with
> Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier.
>
> >From what you say below it seems the intention is to move the struts tags
> which provide functionality that JSTL doesn't have to work in a compatible
> way with JSTL.
>
> Can you clarify this and are you just using the "EL" of JSTL or will your
> ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2?
>
My understanding of what David is proposing is that he's creating variants
of the existing Struts tags, which define attributes that accept JSTL-like
EL expressions rather than the name/property/scope triple that is the
usual Struts approach. Further, the plan is to leverage the expression
language interpreter in the JSTL reference implementation (which is
basically the "standard" taglib from jakarta-taglibs).
It would presumably be possible to extract just the EL interpreter out of
the standard taglib (in fact, this is likely to become a jakarta-commons
package on its own anyway). But it seems to me that this is primarily
targeted for people who want to use JSTL tags in conjunction with Struts
tags -- and, because JSTL requires Servlet 2.3 / JSP 1.2, so would the use
of this tag library extension.
Given the number of Servlet 2.3 / JSP 1.2 containers in the world already
(including every J2EE 1.3 container), it doesn't seem worth any extra
effort to support this EL stuff on Servlet 2.2 / JSP 1.1 (unless it is
trivially simple). And even then, it seems less than useful since you
won't be able to use JSTL tags anyway (so you will miss all the Struts
tags that aren't being ported). I look at this primarily as an extension
library that will work just fine with Struts, but only on Servlet 2.3 /
JSP 1.2 containers.
David, of course, might have different things in mind.
> Niall
>
Craig
> > -----Original Message-----
> > From: David M. Karr [mailto:[EMAIL PROTECTED]]
> > Sent: 22 July 2002 17:19
> > To: [EMAIL PROTECTED]
> > Subject: Status of Struts-EL contrib project
> >
> >
> > I had talked last week about building a tag library, composed of
> > tags derived
> > from the Struts tags, but which use the JSTL expression
> > evaluation engine for
> > attribute values, instead of using JSP rtexprvalues.
> >
> > I thought I would give you a little status on how I'm doing with this.
> >
> > I've finished the "bean" and "logic" libraries, and am now working on the
> > "html" library.
> >
> > It's occurred to me that if I'm building a tag library that would be used
> > alongside the JSTL, there's not much point in porting Struts tags that
> > duplicate JSTL tag functionality. Therefore, most of the tags in
> > the "logic"
> > library aren't in my derived library. Part of the library
> > documentation will
> > cover this issue, and will detail exactly which Struts tags were
> > not ported,
> > and which JSTL tags cover their functionality.
> >
> > While building this, I decided to look at building unit tests for
> > these tags.
> > I thought this would be easy, as I could mutate the unit tests inside the
> > Struts distribution. I was a little surprised to discover that there are
> > actually very few unit tests for the Struts tags, just for "logic:equal",
> > "logic:notequal", "logic:present", and "logic:notpresent".
> >
> > So, as another minor subproject to this, I'm experimenting with
> > what I can do
> > to build more complete unit tests for the Struts-EL tags. Almost
> > all of what
> > I'm doing here could be ported back eventually to the Struts unit
> > tests. In
> > particular, for the tags which generate HTML, I'm writing tests
> > (and reusable
> > support code) which verifies the generated output, including checking the
> > attributes and their values which are present or not present in
> > the output.
> > This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy,
> > AspectJ, and Xalan. Except for Xalan, these all normally go along with
> > HTTPUnit.
> >
> > I'm also going to look at slightly extending the XML files which
> > describe the
> > tag libraries, to include an element which indicates whether an
> > attribute uses
> > the EL engine for evaluation. This won't be used for generating the tag
> > libraries, only for documentation generation.
> >
> > I'll provide more information as I get closer to completion (or
> > what looks like
> > completion to me).
> >
> > Any comments or questions?
> >
> > --
> > ===================================================================
> > David M. Karr ; Java/J2EE/XML/Unix/C++
> > [EMAIL PROTECTED]
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
