On 22 Jul 2002, David M. Karr wrote:
> Date: 22 Jul 2002 09:19:10 -0700
> From: David M. Karr <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> 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.
>
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
