On Tue, 2 Apr 2002, Stephenson Tim wrote:
> Date: Tue, 2 Apr 2002 17:52:46 +1000
> From: Stephenson Tim <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: "Struts mailing list (E-mail)" <[EMAIL PROTECTED]>
> Subject: anyone care to clarify difference between struts and JSTL?
>
> hi all,
>
> i have taken a stroll through the mail archive and not found any clear
> definition of what is the difference between the struts taglibs and the
> 'standard' taglibs.
>
> let me admit first that i am completely new to JSTL, what i really want to
> know is should i keep going with struts tags (which i find very powerful) or
> is everyone about to switch directions?
>
> it seems to me that some tags are overlaps such as the logic tags with what
> appears to be called 'core' condition tags.
>
> and some others have been deliberately (and i believe wisely) excluded on
> grounds on breaking MVC (eg JSTL sql tags)
>
> i would be interested in your views especially in whether you guys see a
> future amalgamation of some or any of the struts tags into JSTL.
>
JSTL, as it's name implies, is (or will be when it goes final in June) the
"standard tag library" that will be portable across *all* servlet/JSP
containers once it is implemented. This has a couple of advantages:
* Page developers will only need to learn one set of tags for the basic
stuff like iterations and conditionals, which will work across all
containers and across all application frameworks.
* Tool developers can afford to spend the time to make their tools aware
of the standard tags -- it's not economically feasible to provide really
high quality support for twenty million different taglibs.
* Container developers can design their page compilers to create optimized
code for the standard version of the tags (such as turning <c:forEach>
into a real Java "for" statement), for better performance.
As you noted, there is a lot of functional overlap with the Struts tags in
the "bean" and "logic" taglibs. That's because, since Struts was around
first, it set a pretty high baseline for what people expected a standard
tag library to include. In fact, the expert group that built JSTL took a
lot of the good ideas directly from the Struts tag libraries, as well as
from several others, and coalesced them (while improving on them at the
same time).
My advice to Struts users is as follows:
* If you're running on a Servlet 2.2 / JSP 1.1 container, you
will not be able to use JSTL (it requires Servlet 2.3 / JSP 1.2).
Go ahead and continue using the Struts tag libraries.
* If you're running on a Servlet 2.3 / JSP 1.2 container, you
should begin experimenting with JSTL. There is no problem in
using both JSTL and Struts tags in the same page (although,
obviously, the expression syntax is different).
* Over time, I plan to add a few features to the Struts tags to
ease migration to JSTL for the "bean" and "logic" libraries --
for example, I want to support the same expression language, and
attribute names where that is possible.
* Longer term, I suggest that page developers plan on using the JSTL
tags in their applications, as quickly as it is feasible for you
to do so. But we're not going to throw away the existing Struts
tags any time soon, so they will continue to be available.
(One other note -- the expression language itself will become part of JSP
1.3, so you'll be able to use it in template text as well as in custom tag
attribute values.)
The same basic story will be my recommendation with regards to JavaServer
Faces, although that will take longer because Faces is not as far as long.
Ultimately, we want to take maximum possible leverage on the features of
JSTL and JavaServer Faces because there will be lots more tools support
for the standard libraries than the Struts libraries could ever gather by
themselves.
Of course, none of this affects your form beans, actions, and the business
logic that they call. Aren't you glad that you followed the recommended
design patterns and split the presentation logic from the business logic?
:-)
> rgds,tim
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
