I agree with Craig. We shouldn't put any more effort into the taglibs than we need to. I am concerned about enhancing a few of the tags like errors and messages because they are struts specific and very useful.

David



From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: Struts taglib
Date: Thu, 31 Oct 2002 13:45:20 -0800 (PST)



On Thu, 31 Oct 2002, [utf-8] Etienne Labonté wrote:

> Date: Thu, 31 Oct 2002 15:50:35 -0500
> From: "[utf-8] Etienne Labonté" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: "Struts Developers List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Struts taglib
>
> Hi,
>
> Are there any plans to untie taglibs from Struts in a future version? In
> many cases I see this wouldn't be too much to ask. Such as in
> org.apache.struts.taglib.bean.MessageTag where there is a dependency on
> org.apache.struts.action.Action only for a few constants. While we are at
> it, are there also plans to move org.apache.struts.util.RequestUtils and
> friends to the Commons project?
>

There isn't any simple answer to that set of questions, but here are my
thoughts:

* For my own efforts, I'm going to de-emphasize improvements
and enhancements to the Struts tag libraries at all, and
encourage people to use the standardized successors (JSTL
now, and JSF when it's done). We should definitely do bugfixes
on the existing libraries after 1.1, but I don't see a good
reason to invest the necessary effort to disconnect
them when standarized (as well as more powerful) solutions
exist. Other committers might see this differently, of course.

* There is very little code in RequestUtils that is not
Struts-specific, so it wouldn't make a particularly good
candidate for commons. You might recall that several
Commons packages did originally come from Struts (beanutils,
digester, resources, validator), so the factoring of what was
horizontally reusable is, IMHO, pretty much done.

We're also, of course, incorporating commons packages that were
originated by others but are useful to us (collections, dbcp/pool,
fileupload, logging) as well, rather than reinventing those wheels.

My personal efforts on the future of Struts are going to be focused on
enhancing the fundamental architecture of the controller, and looking at
things like hierarchical modules, more general command patterns for
Actions, scriptable multi-request dialogs, and things like that.

> Yours,
>
> Etienne
>

Craig



--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp


--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to