>>>>> "Martin" == Martin Cooper <[EMAIL PROTECTED]> writes:

    Martin> Over time, you'll see Struts tags being deprecated in favour of their JSTL
    Martin> equivalents, and eventually being dropped. That won't happen any time soon,
    Martin> though, because we're still committed to supporting Servlets 2.2 & JSP 1.1
    Martin> in Struts, for a while at least.

I recently submitted an enhancement recommendation, which is basically a
contrib library that I wrote, called "Struts-EL".  It is basically the Struts
tag libraries, but with the attributes evaluated using the JSTL EL engine,
instead of rtexprvalues.  Due to the requirements of the JSTL, this could only
be used with a Servlet 2.3 and JSP 1.2 container.

While building this library, I had to evaluate which Struts tags could be
completely replaced by JSTL tags.  In those cases, I didn't port them to the
new library.  In some cases, I decided that even if a tag was similar between
the two libraries, the functionality available in Struts was important enough
to port.

    >> From the 'logic' taglib, I think these are the only ones which do not have
    Martin> JSTL equivalents:

    Martin>   <logic:forward>
    Martin>   <logic:redirect>
    Martin>   <logic:messagesPresent>
    Martin>   <logic:messagesNotPresent>

In particular, even though there is "logic:iterate" and "c:forEach", I felt
there were features in "logic:iterate" that couldn't easily be provided by
"c:forEach" (even though "c:forEach" is still very convenient).

In addition, "logic:match" does not yet have an equivalent in the JSTL, as it
can't match on substrings yet.  My port of this tag (and "notMatch") also added
an "expr" attribute, to allow arbitrary expressions, instead of just from
cookies, headers, parameters, or bean properties.

There is actually a "c:redirect" tag, but it's not as flexible as
"logic:redirect", so that was also ported.

    Martin> and from the 'bean' library:

    Martin>   <bean:resource>
    Martin>   <bean:size>
    Martin>   <bean:struts>

    Martin> Actually, most of the <bean:resource> functionality is available in JSTL,
    Martin> but I think there are some corner cases which are not covered. I'm not sure
    Martin> if <bean:cookie> functionality is available in JSTL or not.

Using "c:import" instead of "bean:resource" only "works" if the resource is not
handled by a servlet.  The latter will give you the raw value of the resource,
the former will give you the output processed by a servlet.  If you really
EXPECT the output from a servlet, then "c:import" is perfectly fine (and more
flexible than "bean:include", as it can specify URLs outside of your
application).

All of the set of "bean:cookie", "bean:header", and "bean:parameter" are
covered in JSTL, as references to objects of those types are directly available
in the EL, so you can just use "c:set" to get those values.

-- 
===================================================================
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]>

Reply via email to