Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <39AB08F9.18469B97@eng.sun.com>
Date: Mon, 28 Aug 2000 17:51:05 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: struts-dev@jakarta.apache.org
Subject: Re: Struts TODO List and Future Planning
References: <11898960E237D411B53B0060B06BB445424636@afexch1.fao.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Lacerda, Wellington (AFIS)" wrote:

> Hi Craig,
>
> I believe segregating the tag library into logically divided sub-libraries
> is a good idea, but I don't agree in separating i18n from forms. If we
> review HTML4.01 we will see that i18n was embedded in every form tag, from
> TEXT to SELECT, at least with 2 attributes: lang and dir (meaning language
> and direction or possibly bi-directional [Chapter 8 of HTML4.01 spec]. So,
> i18n will be everywhere in the interface part of the framework, so this is
> my suggestion of partition:
>

I was specifically thinking of the tags that are sensitive to the Struts concept
of a Locale stored in the user's session, like <struts:message>, but i can see
your point.

>
> Interfacing - <struts:form> and <struts:message>
>
> Logic - as is
>
> Beans - as is
>
> Template - as is
>
> An alternative, if we can't stand with mixing message with forms (not much
> as a sin in my point of view), would be to split interfacing into form and
> text, but in that case text would cope only with the message tag.
>

One thing to remember is that, even if we were to split these tags into separate
taglibs, they would still interoperate just as they do today.  The thing that
would be different is the tag library prefix.

A benefit of splitting that hasn't been articulated yet is that the namespace
for each taglib is unique.  Thus, you can use reasonably short tag names like
"get" in multiple different libraries, if you want to, instead of having to
endlessly invent variations on the same theme in one monster library.

>
> Another thing I didn't see in the TODO that I believe would be nice is some
> kind of mapping for XForms standard under discussion in w3c. What if instead
> of javabeans/EJB my data structures are represented as XML documents ?
>

I am planning to do more personal research in this area.  It fits into the
general topic of decoupling the form tags from their current hard-coded notion
of generating HTML forms, but there is undoubtedly more to it than that.

Thanks for your comments!

>
> Wellington Silva
> UN/FAO
>

Craig