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).
>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.
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.
(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.
(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.
> -- Ted Husted, Husted dot Com, Fairport NY USA.
Craig McClanahan
