You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "David M. Karr" <dm...@earthlink.net> on 2002/07/22 18:19:10 UTC
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++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Struts-EL contrib project
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
>> In any case,
>> just making them available and pointing to them from the "build.properties"
>> will suffice. I don't believe Xalan is required for Cactus, however. That's
>> just used by my code which gets and validates the attributes.
Craig> Xalan is needed to produce the Struts documentation and TLDs anyway, so
Craig> that shouldn't be a problem -- as long as you only need it at compile and
Craig> test time. Are you contemplating a runtime dependency on Xalan as well?
Not runtime of real usage of the library, just test compile and test run.
I didn't notice that Xalan was required for the TLD generation, which is
perfectly logical. I didn't notice because I'm using JDK 1.4, which provides
all that is needed for that. I specifically needed to include Xalan, however,
as JDK1.4 doesn't make the Xalan "XPathAPI" classes visible, which I'm using
for accessing generated attributes (sort of heavyweight for that, but it makes
it very straightforward).
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Struts-EL contrib project
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 22 Jul 2002, David M. Karr wrote:
> Date: 22 Jul 2002 09:53:58 -0700
> From: David M. Karr <dm...@earthlink.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: Status of Struts-EL contrib project
>
> >>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
>
> Craig> On 22 Jul 2002, David M. Karr wrote:
>
> >> 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.
>
> Craig> I would imagine that this (overlap) is also true for some of the tags in
> Craig> the bean library? For example, we probably don't need <bean:define>
> Craig> ported when <c:set> does the same sort of thing.
>
> Yes. The "logic" tags were just an example. I know at least "bean:define"
> wasn't needed, but I don't remember offhand if any others from "bean" weren't
> needed.
ok.
> >> 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.
>
> Craig> That prereq list seems to match what Cactus already requires, right? If
> Craig> so, that should mean nothing extra for me to set up ...
>
> Well, Cactus doesn't necessarily require HTTPUnit, JTidy, or AspectJ, only if
> you use the features of Cactus that need those other libraries. I don't
> believe the existing Struts test cases required any of those.
That's true, to my recollection.
> In any case,
> just making them available and pointing to them from the "build.properties"
> will suffice. I don't believe Xalan is required for Cactus, however. That's
> just used by my code which gets and validates the attributes.
>
Xalan is needed to produce the Struts documentation and TLDs anyway, so
that shouldn't be a problem -- as long as you only need it at compile and
test time. Are you contemplating a runtime dependency on Xalan as well?
Craig
> --
> ===================================================================
> David M. Karr ; Java/J2EE/XML/Unix/C++
> dmkarr@earthlink.net
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Struts-EL contrib project
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Craig" == Craig R McClanahan <cr...@apache.org> writes:
Craig> On 22 Jul 2002, David M. Karr wrote:
>> 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.
Craig> I would imagine that this (overlap) is also true for some of the tags in
Craig> the bean library? For example, we probably don't need <bean:define>
Craig> ported when <c:set> does the same sort of thing.
Yes. The "logic" tags were just an example. I know at least "bean:define"
wasn't needed, but I don't remember offhand if any others from "bean" weren't
needed.
>> 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.
Craig> That prereq list seems to match what Cactus already requires, right? If
Craig> so, that should mean nothing extra for me to set up ...
Well, Cactus doesn't necessarily require HTTPUnit, JTidy, or AspectJ, only if
you use the features of Cactus that need those other libraries. I don't
believe the existing Struts test cases required any of those. In any case,
just making them available and pointing to them from the "build.properties"
will suffice. I don't believe Xalan is required for Cactus, however. That's
just used by my code which gets and validates the attributes.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Struts-EL contrib project
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 22 Jul 2002, David M. Karr wrote:
> Date: 22 Jul 2002 09:19:10 -0700
> From: David M. Karr <dm...@earthlink.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> 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.
>
Cool!
> 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.
>
I would imagine that this (overlap) is also true for some of the tags in
the bean library? For example, we probably don't need <bean:define>
ported when <c:set> does the same sort of thing.
> 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".
>
I know :-(.
> 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.
>
That prereq list seems to match what Cactus already requires, right? If
so, that should mean nothing extra for me to set up ...
> 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.
>
That would be super, and is one of the reasons I chose to generate the
TLDs from a separate XML file that could contain additional information.
> 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++
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Struts-EL contrib project
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Niall" == Niall Pemberton <ni...@btinternet.com> writes:
Niall> David,
>> From your original post I assumed you were going to provide "JSTL" style
Niall> struts tags by incorporating the "EL" functionality of JTSL (I read
Niall> somewhere it was going to be split out from the JSTL, perhaps to commons)
Niall> with the main aim being that struts developers could use them now (with
Niall> 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
Niall> which provide functionality that JSTL doesn't have to work in a compatible
Niall> way with JSTL.
Niall> Can you clarify this and are you just using the "EL" of JSTL or will your
Niall> ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2?
Hmm, I was not aiming for a Servlet 2.2 solution, but it's possible that could
happen. As you suggested, I'm only implementing the Struts tags which provide
functionality not in the JSTL. I'm implementing them by using the internal EL
engine from the JSTL. If we were to try to get it work with Servlet 2.2, you
would essentially have to use both sets of Struts tag libraries (and not use
the JSTL tags at all). You would use this library to get the JSTL
functionality, and the regular library to get the functionality I'm not
porting. I believe that can work, although I'm not directly testing for that.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Status of Struts-EL contrib project
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 23 Jul 2002, Niall Pemberton wrote:
> Date: Tue, 23 Jul 2002 03:28:22 +0100
> From: Niall Pemberton <ni...@btinternet.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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:dmkarr@earthlink.net]
> > Sent: 22 July 2002 17:19
> > To: struts-dev@jakarta.apache.org
> > 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++
> > dmkarr@earthlink.net
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Status of Struts-EL contrib project
Posted by Niall Pemberton <ni...@btinternet.com>.
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?
Niall
> -----Original Message-----
> From: David M. Karr [mailto:dmkarr@earthlink.net]
> Sent: 22 July 2002 17:19
> To: struts-dev@jakarta.apache.org
> 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++
> dmkarr@earthlink.net
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>