We would want to think carefully about including custom tags in such an
extension scheme. For tags that are truly Struts-specific, this might be
reasonable. However, even some of the Struts tags are no longer
Struts-specific, since they are now based on Commons code.
For non-Struts-specific tags, we might want to encourage people to amble on
over to our neighbour, the Jakarta taglibs project, rather than add them as
Struts extensions.
--
Martin Cooper
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 2:39 AM
Subject: [PROPOSAL] Struts Extensions
> [ This suggestion based on a conversation with Roland Huss ]
>
> "Craig R. McClanahan" wrote:
> > In future versions of Struts we will be integrating the ability to
create
> > client side validations.
>
> As we start work on the 1.1 task list, I would like to suggest that we
> start thinking in terms of a core Struts framework that can be
> supplemented by any number of extensions. (As Roland Huss put it,
> something like Java and Javax.)
>
> A good example of this is David Winterfeldt's Validator servlet. The
> design plugs cleanly into the framework by extending the standard
> classes. Once it is there, it feels like it part of the framework (I
> even configure it from struts-config!) -- but I could just as easily
> leave it out if I wanted. Or plug in another Validator instead.
>
> The same would probably be true of Oleg's BeanFactory. Plug it in. Plug
> it out. Plug in something else.
>
> Struts now has the reputation of being a "lightweight" framework, which
> I think is a very good thing. But at the same time, we would all like to
> see Struts enhanced with additional functionality. If we start to add
> that functionality by encouraging an extension model, we can keep the
> core framework lean and still provide the advanced functionality many
> applications need.
>
> This would also encourage an environment where developers can develop a
> full-blown extension -- like Cedric and David have done, and Oleg is
> doing -- gain community support, and then have it voted into the
> distribution. But, once voted in, it would not bloat the core
> distribution, but be a true enhancement that people could snap in by
> choice.
>
> Another good place to do this is with the taglibs. Besides the standard
> tags, we might also distribute a struts-ext library with tags that,
> while useful, you may not need to write a standard application. This
> library may be closer to a "sandbox" or a "commons" than the libraries
> we distribute now. A tag might start here in a nightly distribution (via
> a Committer), and some might eventually be moved to the core
> distribution if many people come to consider it indispensible. This
> would relieve the pressure of deciding whether a tag needs to part of a
> lightweight framework, while encouraging developers to share their work
> with the rest of the community.
>
> So my proposal is that Struts 1.1 be organized into a core framework
> distribution, as we have today, supplemented a struts-ext distribution
> with standard enhancements. This would be a bundling change only, and
> entering new packages into the struts-ext distribution would be held to
> the same high standard as the core framework.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
