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. 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? Vic 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]>
