On Mon, 22 Jul 2002, Struts-dev Newsgroup wrote:
> Date: Mon, 22 Jul 2002 10:25:01 -0700
> From: Struts-dev Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Status of Struts-EL contrib project
>
> Subject: Re: Status of Struts-EL contrib project
> From: "Vic C." <[EMAIL PROTECTED]>
> ===
> It appears that only HTML tag would need "conversion". ?
>
> I would think that logic and bean tag would be deprecated over time
> since there is JSTL equivalents as Craig mentioned before, if I recall.
>
That kind of deprecation wwould happen in some future rev of Struts. For
1.1, we still require only Servlet 2.2 / JSP 1.1 as prerequisites, and the
library that David is working won't be added to the core of 1.1, since
JSTL requires Servlet 2.3 / JSP 1.2.
I suspect the same sort of thing will happen (ultimate deprecation but
continued support) for most of the html tag library, once JavaServer Faces
becomes available.
> Also, I have posted an example on sourceforge (basicPortal) of an JSTL
> for each tag with struts HTML for multi row update(it has a minor bug
> now - approve content page), should that be of use. I will continue to
> write "realistic" sample of using Struts with JSTL so should you need
> "web app sample" I will be incorporating what ever you post ASAP.
> Where would you post it?
>
Better multi-row support in general, and master-detail in particular, are
two areas on my wish list for direct support by Struts in a post-1.1
release. Whether we end up building them on top of JSTL and Faces tags,
or implement them separately, will be an interesting design decision.
In the mean time, having realistic examples is very useful for people who
need this kind of thing now instead of later, as well as to validate the
functional requirements.
> Vic
>
Craig
>
> David M. Karr wrote:
> >>>>>>"Craig" == Craig R McClanahan <[EMAIL PROTECTED]> 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.
> >
>
>
> --
> 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]>
