See intermixed.
On Tue, 23 Apr 2002, Jing Zhou wrote:
> Date: Tue, 23 Apr 2002 18:09:33 -0500
> From: Jing Zhou <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Another way to find mapped properties
>
>
> ----- 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.
>
If we are going to adopt the JSTL (and JSP 1.3) expression language
syntax, I believe we should adopt all of it, not just a subset. For
example, consider the <bean:write> tag, where you use the "name" and
"property" (plus optional "scope") attributes to identify the property to
be written. The "property" attribute takes one of our proprietary
expressions, so you can say something like:
<bean:write name="customer" property="address.city" scope="session"/>
The equivalent using a standard JSTL tag would look like this:
<c:out value="${sessionScope.customer.address.city}"/>
or, if you wanted to leave out the scope (just like omitting the "scope"
attribute on a Struts tag) you would just say:
<c:out value="${customer.address.city}"/>
To make it easier to learn the new EL syntax, one thing JSTL does very
nicely is use standardized attribute names for all their tags. So, we can
consider using a "value" attribute on <bean:write> that accepts the new EL
syntax, as an alternative to the name/property/scope triplet:
<bean:write value="${sessionScope.customer.address.city}"/>
where the attribute name "value" indicates that the new EL syntax is
supported (just like all of the existing Struts tags use "property" as the
attribute name where our own expressions are recognized).
Of course, we would continue to support the existing attributes for
backwards compatibility, but people would be able to learn and apply the
new syntax in a gradual manner. The JSTL convention of using "value" for
the attribute name when an EL expression is allowed would be the clue to
the user about which syntax should be used.
> 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.
>
While I can see how this would be nice for a business professional, I
think it would be pretty constraining for people who are professional page
developers and/or Java developers. To say nothing of business
professionals who *think* they can design web pages, or who find it to be
kind of fun ...
> Do I return to JSP 1.0 spec by allowing expressions in property attributes?
Note that the expressions I'm talking about are in the new EL language
syntax -- not runtime expressions in the JSP 1.0 sense. As you can see
from the above example, the syntax is very close to the kind of things
that Struts users are used to for property access. And the ability to
collapse three attributes into one will appeal to folks who don't like to
do all the typing.
> 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)
I would bet that most Struts apps use request scope for form beans (for
better scalability), but that is somewhat peripheral to your point.
> 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.
>
It would be technically feasible to provide an expression evaluation
context that started with the form bean -- but I believe that in
general this is really constraining on your page designs. It's perfectly
reasonable, for example, to cache data in application scope at startup
time (such as the options list for SELECT boxes), and reference them in
your JSP page using the <html:options> tag.
> 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)
>
Note that the JSTL expression language supports nested access (via the "."
operator), just like Struts expressions do. It also supports indexed and
mapped lookups (with slightly different syntax for the latter), plus a
whole bunch of stuff that Struts tags do not support -- such as real-life
actual expressions :-). Because of this, a lot of the Struts tags
(especially in the logic taglib) become redundant because using an
expression is so much more concise. For example:
<c:if test='${(customer.status == "CLOSED") ||
(customer.status == "HOLD")}'>
No orders can be entered for accounts that are
closed or on credit hold!
</c:if>
> 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.
>
My personal opinion is that, of the things that have made Struts very
popular, one of the most important is the freedom we've given to page
designers to navigate trees of JavaBeans via the "property" expression
syntax. What's even more important (and is done better in JSTL than in
our language), the expression language can hide away the actual
implementation technology that was used by the business logic folks.
Consider the expression ${customer.status}. With the JSTL, the same
expression is used for all of the following circumstances:
* "customer" is a JavaBean with a getStatus() method.
* "customer" is a Map with a key value of "status".
* "customer" is a JDBC Row with a column named "status".
The business logic developer can change how the data is provided, without
requiring any changes to the pages using this expression.
Now, I'm talking about the general purpose case. There is definitely a
use case for restricted capabilities, exposed only through tools, to
casual or data-browser type users. But I suspect that the more
sophisticated of those folks will quickly chafe against the restrictions
of what concepts you expose to them. I would consider ways to make your
tools help this sort of user assemble the expressions they need (perhaps
by visually navigating the object tree) rather than just banning them.
Looking down the road, it is also worth remembering that this very same
expression language will be included in JSP 1.3. That means you will be
able to use it, not just in custom tag attributes, but in template text as
well (basically, anywhere you could use a runtime expression today). Lots
and lots of developers are going to be using this stuff to make flexible
and sophisticated application UIs.
> Thanks,
>
> Jing
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
