----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 23, 2002 3:04 PM
Subject: Re: Another way to find mapped properties
>
>
> On Tue, 23 Apr 2002, Jing Zhou wrote:
>
> > Date: Tue, 23 Apr 2002 13:29:40 -0500
> > From: Jing Zhou <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Another way to find mapped properties
> >
> > Struts 1.1 will introduce mapped property in the form beans.
> > The PropertyUtils find it by looking for patterns:
> > property_name{mapped_key}
> >
> > I am not aware of any in depth discussion about using
> > { } as a mapped property key identifier before, but I have
> > several concerns about the use of { }.
> >
> > * In XSLT spec as well as JSTL spec, { } is used for
> > expressions.
> >
> > * We can use property_name[mapped_key] to identify
> > a mapped property in the following algorithm:
> >
> > When see property_name[string_literal], test the first
> > character to see it is digit or not. if not, treat the
> > string_literal as mapped key. Otherwise, parse the
> > string_literal into int, if parsing successfully, treat it
> > as int index. If exception occurs, treat it as mapped key.
> >
> > I did this some time ago, because I see people can do
> > document["href"] in JavaScript, and element[non_integer_index]
> > in XML style sheet.
> >
> > * If we could reserve the { } for expression, we may see
> > Struts addressing pattern like this in the future:
> >
> > a.b[{$i}].c[{$j}], or simply a.b[$i].c[$j]
> > where {$i}, {$j} come from JSP scoped variables or tool scoped
> > variables. It solves multi-loop problems too. Implementation is
> > relative easy, just like what you do for indexed attributes
> > prepareIndex() in BaseHandlerTag. Another function
> > prepareProperty(...) will evaluate any expressions in property
attributes.
> >
> > Could some Struts experts share your thinking on this subject
> > and advise me any pros or cons of this approach?
> >
>
> Well, the mapped property handlers actually use parentheses ("(" and ")")
> instead of curly braces ("{" and "}"). Does that alleviate your concern?
My mistake to take parentheses as curly braces. So I still have a chance to
use { }, but not very encouraged on the existing attributes. But I still
have some additional questions, a little bit off Struts.
>
> My belief is that we should ultimately migrate to using the same
> expression language used in JSTL (and what will be used in JSP 1.3). For
> the most part, we can accomplish that by adding new attributes to existing
> Struts tags that recognize the new syntax -- and leave the existing
> attributes alone. The new attribute names would match (as much as
> possible) the JSTL conventions for names.
>
> Does that make sense?
>
> > Thanks,
> >
> > Jing
> >
>
> Craig
>
I know it is possible too early to ask what the new syntax is going to look
like
in the future version of Struts. But I could provide what lead me to think
to
use a mini expression evaluator for the property attributes.
Our tool is for business professional, to make things simple, I would like
to
give them only the property, validation rules, and html related attributes
on a screen for <html:text /> as an example. When some advanced users
want to explore iteration tags, for example, they could easily do it by
entering the property field with some simple expressions. Therefore I do not
need to put a check box on the screen for the "indexed" attribute to confuse
majority of users.
Do I return to JSP 1.0 spec by allowing expressions in property attributes?
In our controlled environment, users only have ONE place, form bean model
to define variables with only two possible scopes, session, or shared.
Thanks to your multiple sub-application support, people could shared
variables
in a sub-application. So there is no page scoped, no request scoped, and
no application scoped variables for average users (This is our security
requirement that allow thousands of users to build mini web forms on one
site)
Therefore, any expressions when evaluated will import or export values
from or to the form beans, no other places. As the result, I feel I could
build a
"perfect" MVC visual model for the mass, even they do not know what
MVC means.
When I looked at JSTL spec 1.0, this kind of "perfect" will lost in the
standard
implementations, because there is no direct model concept in JSTL (they
import or export to JSP scoped variables and the deep nested property
addressing is lost too)
It is my understanding that Struts and JSTL are designed to take care of
developers needs in most cases. When you have a controlled environment,
do you think my motivation is legitimate or it is a bad idea at all? I am
not
going to implement any expression things in the near future, I am really
interested in any advice from Struts experts.
Thanks,
Jing
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
