jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject Re: Struts taglibs and the Taglibs project, part 2
Date Tue, 13 Mar 2001 22:41:23 GMT

--- "Craig R. McClanahan" <craigmcc@apache.org> wrote:
> On Tue, 13 Mar 2001, Ted Husted wrote:
> > Morgan Delagrange wrote:
> > > Right now, I'm inclined to create a new tag
> library in
> > > Taglibs that mimics portions of the Struts tags.
>  I
> > > think the duplication is justifiable.  Ideally
> this
> > > would not be necessary, but I think that the
> Struts
> > > tags are just too, well, Struts-ish for
> developers who
> > > are not working inside that framework.  (This is
> not a
> > > criticism, just an observation!)  And of course,
> any
> > > new approaches we develop in scopes (e.g. I
> don't see
> > > any init parameter support in the Struts tags)
> can be
> > > picked up by Struts too.
> > 
> > That seems like a sensible approach, Morgan.
> Here's a clip from a Struts
> > FAQ I'm drafting. 
> > 
> > "Why aren't the Struts tags maintained as part of
> the Jakarta Taglibs
> > project?
> > 
> > "A few of the Struts tags could be maintained
> outside of the framework,
> > but most accept parameters that are in someway
> tied to the rest of
> > Struts, especially references to the Controller's
> action mappings. This
> > is an important feature, since it allows the view
> to be developed using
> > logical forwards, which could be maintained by
> another team. Ironically,
> > for the view to be "loosely coupled" to the
> Controller, most of the view
> > tags need to be tightly coupled to the framework."
> > 
> Sorry I haven't had time to respond to this thread
> yet -- I was on the
> road for the last two weeks, and am only now
> catching up on email.
> There are several tag libraries that are part of
> Struts, and each has a
> different amount of dependency on the rest of the
> framework that would
> make it more or less amenable to being separated. 
> This will be overviewed
> further below, but I'd like to discuss a philosophy
> issue first.
> There is an ongoing effort (JSR-052) to create a
> standard tag library for
> JSP pages.  It is very likely that some of the
> functionality of some
> existing tags will get incorporated into the
> standard tag library --
> whether or not it looks like the Struts tags of
> today is up to the expert
> group on JSR-052.  Once that happens, it is likely
> that existing Struts
> users would need to retrofit their existing apps to
> use the new standard
> versions of the tags (Struts would continue to
> support it's own version as
> a transition, of course).

Good point.  I wish I had a better understanding of
when the JSR-052 effort will be completed.  They've
been working at it for quite a while. 

> From the viewpoint of Struts developers, however, it
> would be MUCH more
> painful to have to go through two transitions
> (Struts --> Taglibs -->
> Standard).  If I can hide the transition to Taglibs
> behind the existing
> struts-xxxxx.tld files (so that user pages don't
> have to be modified), I'm
> OK with that.  If I need to force users through two
> conversions, then I'm
> not going to be in favor of the proposed migration.

I think I agree.  It's probably better for the Struts
taglibs to remain in their current location (if there
are no objections).  Maybe Taglibs will work on its
own set of tags, if it seems appopriate.

> In terms of general purpose applicability, let's
> look at the various
> Struts tag libraries individually:
> (1) struts-bean.tld
> From a user point of view, these tags are very
> general purpose.  However,
> they have the following dependencies on other Struts
> internals:
> - The <bean:struts> tag exposes Struts internal
> objects, and is not
>   appropriate in a general purpose library.
> - In all cases where tags throw a JspException, they
> also record the
>   underlying exception in a specific request
> attribute with a Struts
>   related name.
> - The extended property getter/setter syntax depends
> on a suite of utility
>   classes (BeanUtils/ConvertUtils/PropertyUtils). 
> There is ongoing
>   discussion of making this code a contribution to
> the new Jakarta
>   Commons project to be proposed - until that
> happens, they will remain
>   dependent on Struts.
> - The <bean:message> tag, which supports
> internationalization, depends
>   on a Struts-specific architecture for message
> resource bundles.
>   Originally, we used java.util.ResourceBundle but
> had to abandon this --
>   many application servers require that servlet
> context attributes
>   be Serializable (in addition to session
> attributes), and the
>   java.util.ResourceBundle family of classes is not.
>  A general purpose
>   version of this should depend on a general purpose
> resources framework
>   (perhaps also part of the new Commons project)
> instead.
> - The internal implementations of all of these tags
> depends on the
>   same message resources infrastructure for looking
> up internationalized
>   message strings for exceptions.
> There is also *substantial* overlap between the
> functionality of these
> tags and existing packages in jakarta-taglibs.

Is this a good thing, bad thing, or just an
observation?  Historically, I don't know if Glenn's
work or Struts taglibs came first, but while they
address some of the same features, their approaches
differ, sometimes significantly.  (And, of course,
Struts has features that Taglibs would not be able to
implement outside the framework.)  I'm very interested
to see if the "Foundation" taglib moves closer to or
further away from Struts.  If it becomes even more
similar, perhaps it is not even necessary.  Of course,
this is assuming that the Foundation tag libraries can
stand on their own.

> (2) struts-html.tld
> The majority of these tags have substantial
> dependencies on the remainder
> of the Struts framework, and are not particularly
> amenable to general
> purpose use.

Fair enough.

> (3) struts-logic.tld
> These tags are general purpose from the user's point
> of view.  They have
> the following dependencies on the remainder of the
> Struts framework:
> - Same dependencies as struts-bean.tld related to
> JspExceptions,
>   extended property getters/setters, and message
> resources
> - <logic:forward> and <logic:redirect> have options
> for forwarding or
>   redirecting that depend on Struts internals.


> (4) struts-template.tld
> These tags are the least dependent on Struts
> internals.  This library is
> also slated to be substantially improved in Struts
> 1.1.


> It should also be noted that all of these tag
> libraries can easily be used
> in non-Struts-based applications already -- simply
> put the appropriate TLD
> files in WEB-INF, and struts.jar into WEB-INF/lib,
> and you are off and
> running.

Really, there is no configuration required to use the
tag libraries by themselves?  I guess I had assumed
that the taglibs would barf if I didn't implement the
Struts Servlet controllers.  Well, I'll experiment
with it a little and see how the tag libraries works
stand-alone.  Perhaps, if the tags do what I need,
I'll use Struts, since Foundation is still in its

However, I remain a little suspicious of using tag
libraries coupled to frameworks when I'm not using the
framework itself.  There are no guarantees that future
releases won't tighten the coupling, essentially
making the tag library useless outside the framework. 

The Struts tag libraries don't seem to have any
support for init parameters, is that right?  Is that
an oversight?  If so, I would definitely consider
contributing an update, if Struts turns out to be
useful for me.

- Morgan

Morgan Delagrange

Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.

View raw message