struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Taglibs Plans?
Date Tue, 10 Apr 2001 18:13:52 GMT

On Tue, 10 Apr 2001, Dana Kaufman wrote:

> Pierre,
> Thank you for responding to my inquirary.  I guess the root of these
> question come from a statement someone made to me.  They mentioned that
> they read somewhere that Struts was going to be included in the next
> Sun J2EE specification.  I could be wrong on this point as I have not
> read anything about it myself.  

That statement goes quite a ways beyond anything that *I* (as primary
author of Struts) understand to be the case :-).  Also, you can see the
"Proposed Final Draft" version of the J2EE Specification (which qualifies
as the "next" version in my book) by following the documentation links at

What you will see over time is some synching up between the web layer
described in the J2EE Blueprints documents and the model suggested by
Struts.  But that is different from being part of the specification

> It naturally brought up the question about future planning.  What will
> be avaliable via all containers in the future, how do the various tag
> libs interact, what effect on one project does the inclusion of the other
> technologies in the specifications, etc?

I believe you can count on the following:

* At some point in time, all containers will support the "JSP Standard
  Tag Library" (or whatever the result of the JSR-052 effort is called)
  out of the box.  Because the APIs for these tags will be standardized,
  you will likely see advanced containers make their JSP page compilers
  smart about the code they generate for these tags (in the same way
  that most containers understand things like <jsp:useBean>.  But this
  will not make any difference to what the page author is free to use.

* All custom tags that conform to the JSP 1.1 specification (which
  includes, but is not limited to, the tags that available in both
  Struts and Taglibs) will work on *all* JSP 1.1 containers.  The
  compatibility story is fairly good already, and getting better all the
  time.  Web applications will simply include the tag libraries they
  need (TLD and JAR files), and will work with no problems.

* Custom tag libraries based on the JSP 1.1 specification will also
  work correctly on containers that implement the JSP 1.2 specification
  (currently in Proposed Final Draft statius), such as Tomcat 4.0 beta 3.
  The spec requires backwards compatibility for this, as well as for
  servlet 2.2 (JSP 1.2 goes hand in hand with Servlet 2.3).

> I see some overlap between Struts and the Taglibs project.  I also saw
> the Standard Tag Libraries and wondered if it was the same project as
> Taglibs (or the intent to make the Taglibs project the standard).  If
> Struts is truly going to be part of the new speifiations, it seems to
> make sense to sync up the two projects.

Struts and Taglibs started at roughly the same time, but with different
goals.  Struts was aimed at being an "all in one" framework solution,
while Taglibs was aimed at being a repository for libraries with
(possibly) overlapping functionality.  As Pierre mentions, there have been
some discussions of abstracting out the non-framework-dependent tags in
Struts, and migrating them to Taglibs.  My personal view is that I'd
rather migrate Struts users to the ultimately approved standard tags (in
one move) rather than migrating to Taglibs and then to the standard -- but
that decision is certainly open to the community for discussion.

Both the Taglibs tags and the Struts tags are being examined in the
JSR-052 process (along with other submissions).  My personal belief is
that the standard tags will end up being a synthesis of the best ideas
from all sources, so they won't look precisely like any particular
existing library.  But, of course, the compatibility of custom tags across
containers means that a developer can pick and choose what they want to
use now, and migrate later if they want to.

> Regards,
> Dana Scott Kaufman

Craig McClanahan

View raw message