Thanks so much for providing detailed information on Struts.
It helps me to make sure my tool will stay in line with the
future features. See my response intermixed.
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 23, 2002 7:56 PM
Subject: Re: Another way to find mapped properties
> 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}"/>
>
Can we have syntax like this in Struts?
<bean:write name="customer" property="address[${key}]" scope="session"/>
or in JSTL
<c:out value="${sessionScope.customer.address[${key}]}" />
Where the evaluated value of ${key} at runtime could be obtained from
a loop tag or a tool provided model. An example value of ${key} could be
0, 1, 2 ... as a looped index, or "home", "ship_to", "charge_to", etc.
I feel the true problems I am struggling for are better expressed in the
above
examples. A more agressive syntax may looks like:
<html:text name="customer" property="${whatever property to post}" />
or something like:
<html:text name="customer" property="${foo1}normal_string${foo2}"/>
I am not sure JSTL could understand the "nested expressions" or not and
how to express them in JSTL. The idea is somehow we could dynamically
assemble the string literal for the "property" attributes.
> 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 ...
>
I position our tool as a productivity tool rather than as a developer
tool
for these who know html and want to publish their exam/testing forms for
their students, or survey forms for their customers, etc. Of course,
there
should be templates for vertical solutions, where they could invoke
advanced features provided by tool developers at back ends. The
tool will benifit both tool users and tool developers.
> > 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.
>
It is possible for me to think again if I can "deprecate" request scoped
objects
for tool users. Of course, tool developers should be able to use them.
> > 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.
>
The way of our tool to let people share cached data is through the
sub-application scoped objects, which will be initialized at startup time.
The reason in doing so is that I could not trust the tool users in general.
If they can access applicaton scoped objects, they may close my data
source connection pools :-) Of course, tool developers should be
able to use whatever scoped objects.
> > 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.
Our tool does have the capability to let users assemble object trees in
any depth. The root object could be defined as session scoped or shared
in sub-application. The bean property could be defined as basic
(simple or custom bean), array, list, map, model (allow nested form bean
models), shared (point to sub-application shared objects) and temp.
We also have the capability to assemble view models for JSP as well
as controller models.
The temp property will replace the page scoped objects where we hope
iterator tags on the view will expose current variable to it and
nested tags could access those temp properties. Especially I hope
the nested tags could use the syntax we discussed earlier. If this feature
can be achieved, our form bean model is somewhat "self completed"
in a sense that tool users do not need any other places (on our view
model or controller model) to define objects. This is what I mean in
a "perfect" MVC visual model, which have a little of restriction for
tool users, but we do not have any restrictions for tool developers.
Thanks,
Jing
>
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
