You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jing Zhou <ji...@netspread.com> on 2002/04/23 20:29:40 UTC
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?
Thanks,
Jing
Re: Another way to find mapped properties
Posted by Jing Zhou <ji...@netspread.com>.
The clouds in my mind over the JSTL EL are finally cleaned up.
We are going to have a more compact set of attributes for STRUTS
(Actually it become easy for me to normalize screen objects,
if understanding correctly, <html:text /> should have an extra
attribute to hold ${scope.name.property} in the future)
Thanks,
Jing
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Thursday, April 25, 2002 4:01 PM
Subject: Re: Another way to find mapped properties
>
>
> On Thu, 25 Apr 2002, Jing Zhou wrote:
>
> > Date: Thu, 25 Apr 2002 15:09:31 -0500
> > From: Jing Zhou <ji...@netspread.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Re: Another way to find mapped properties
> >
> > I browsed the Appendix A for EL and got the following
> > thoughts:
> >
> > Suppose STRUTS taglib is running in a JSTL environment
> > with EL engine enabled. We could have a construct like
> >
> > <c:forEach var="i" items="some_address_index_collection">
> > <bean:write name="customer" property="address[${i}]"/>
> > </c:forEach>
> >
> > I hope the EL will set the property attribute with string
> > literal address[0], address[1], ... at runtime.
> >
> > Craig, is the above construct legal in the future? It looks
> > to me pretty neat when considering arbitrary string literal
> > could be set by the EL engine (it also solves my problem)
> >
>
> We won't know for sure until we actually modify Struts to support the EL,
> but I anticipate that you would (in the future) code this example as
> follows:
>
> <c:forEach var="i" items=some_address_index_collection">
> <bean:write value="${customer.address[i]}"/>
> </c:forEach>
>
> The reasons for the changes:
>
> * I would like to use a new attribute ("value") on the Struts tags
> for the places that EL expressions are legal, so that we don't
> mess up the existing use of the "name" and "property" attributes
> where the old syntax would continue to work as it always has.
> In addition, use of "value" as an attribute is consistent with the
> JSTL conventions for attribute names.
>
> * In the JSTL EL, once you are inside "${...}" then everything is
> interpreted as an expression - you don't need nested "${i}" to
> make "i" be treated as a variable reference.
>
> Until after Struts 1.1, this is all just drawing on a whiteboard, but it's
> definitely the direction I am thinking about.
>
> > Jing
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 25 Apr 2002, Jing Zhou wrote:
> Date: Thu, 25 Apr 2002 15:09:31 -0500
> From: Jing Zhou <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Another way to find mapped properties
>
> I browsed the Appendix A for EL and got the following
> thoughts:
>
> Suppose STRUTS taglib is running in a JSTL environment
> with EL engine enabled. We could have a construct like
>
> <c:forEach var="i" items="some_address_index_collection">
> <bean:write name="customer" property="address[${i}]"/>
> </c:forEach>
>
> I hope the EL will set the property attribute with string
> literal address[0], address[1], ... at runtime.
>
> Craig, is the above construct legal in the future? It looks
> to me pretty neat when considering arbitrary string literal
> could be set by the EL engine (it also solves my problem)
>
We won't know for sure until we actually modify Struts to support the EL,
but I anticipate that you would (in the future) code this example as
follows:
<c:forEach var="i" items=some_address_index_collection">
<bean:write value="${customer.address[i]}"/>
</c:forEach>
The reasons for the changes:
* I would like to use a new attribute ("value") on the Struts tags
for the places that EL expressions are legal, so that we don't
mess up the existing use of the "name" and "property" attributes
where the old syntax would continue to work as it always has.
In addition, use of "value" as an attribute is consistent with the
JSTL conventions for attribute names.
* In the JSTL EL, once you are inside "${...}" then everything is
interpreted as an expression - you don't need nested "${i}" to
make "i" be treated as a variable reference.
Until after Struts 1.1, this is all just drawing on a whiteboard, but it's
definitely the direction I am thinking about.
> Jing
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by Jing Zhou <ji...@netspread.com>.
I browsed the Appendix A for EL and got the following
thoughts:
Suppose STRUTS taglib is running in a JSTL environment
with EL engine enabled. We could have a construct like
<c:forEach var="i" items="some_address_index_collection">
<bean:write name="customer" property="address[${i}]"/>
</c:forEach>
I hope the EL will set the property attribute with string
literal address[0], address[1], ... at runtime.
Craig, is the above construct legal in the future? It looks
to me pretty neat when considering arbitrary string literal
could be set by the EL engine (it also solves my problem)
Jing
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, April 24, 2002 2:38 PM
Subject: Re: Another way to find mapped properties
>
>
> On Wed, 24 Apr 2002, Jing Zhou wrote:
>
> [snip]
> > > [Craig said]
> > > 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"/>
>
> This is not curently legal. Struts only accepts integer literals as
> subscripts, although you can fake it with a runtime expression:
>
> <bean:write name="customer"
> property='<%= "address[" + key + "]" %>' scope="session"/>
>
> > or in JSTL
> > <c:out value="${sessionScope.customer.address[${key}]}" />
>
> In this case, it would actually be:
>
> <c:out value="${sessionScope.customer.address[key]}"/>
>
> You don't really need to wonder what the JSTL expression language syntax
> is -- you can download the JSTL spec and read Appendix A.
>
> http://jcp.org/aboutJava/communityprocess/first/jsr052/
>
> > 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.
> >
>
> There are two variations of the JSTL library -- one that accepts runtime
> expressions (like the Struts case above) and one that does not.
>
> [snip]
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Multi Device Web Application
Posted by Manuel Vilar <mv...@neocom.fr>.
Hello !
I am learning to use STRUTS and TILES to make a multi-device ( for example
"text/html" and "text/another-ml" ) web application.
I have been dealing with tiles channels and struts action servlet ( and
tiles extension one ) to set the good channel key in a session attribute
( depending of the request header "user-agent" info ).
Then, depending of the session channel key, (struts and tiles ) action
processContent() will set the good contentType.
So I have two componentDefinitions, each one corresponding to each client
device tiles definitions.
It's a good example of tiles channels possibilities ( thanks to Cedric
Dumoulin ) !
When the received request is mapped to my ActionComponentServlet ( mapping
"*.do" to ActionComponentServlet ) which extends Struts Action servlet,
I succeed to forces the content type, and everything seems ok for actions
responses.
But the leak, is when the request concern just any "page.jsp" wich isn't
mapped, of course, to my ActionCOmponetServlet.
If the page does not contain any contentType directive, because we use a
tiles tag to insert a componentDefinition,
only included jsp pages ( using appropriated device-channel ) have to
contain the good device contentType directive.
It doesn't works at all !
The contentType of include pages is just ignored, and the missing main page
contentType is just
setted to default contentType : "text/html" by the JSPServlet ( I think ) !
Aaaaargh
The best way, I think, would be to override the default content type setted
by the JSPServlet or any other
Servlets ( php, cgi, etc.. )
Have you some idea of how could I achieve that ?
Thanks in advance to all the reader,
Manuel VILAR
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 24 Apr 2002, Jing Zhou wrote:
[snip]
> > [Craig said]
> > 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"/>
This is not curently legal. Struts only accepts integer literals as
subscripts, although you can fake it with a runtime expression:
<bean:write name="customer"
property='<%= "address[" + key + "]" %>' scope="session"/>
> or in JSTL
> <c:out value="${sessionScope.customer.address[${key}]}" />
In this case, it would actually be:
<c:out value="${sessionScope.customer.address[key]}"/>
You don't really need to wonder what the JSTL expression language syntax
is -- you can download the JSTL spec and read Appendix A.
http://jcp.org/aboutJava/communityprocess/first/jsr052/
> 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.
>
There are two variations of the JSTL library -- one that accepts runtime
expressions (like the Struts case above) and one that does not.
[snip]
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by Jing Zhou <ji...@netspread.com>.
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" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
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 <ji...@netspread.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Re: Another way to find mapped properties
> >
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <cr...@apache.org>
> > To: "Struts Developers List" <st...@jakarta.apache.org>
> > 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 <ji...@netspread.com>
> > > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > > To: Struts Developers List <st...@jakarta.apache.org>
> > > > 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Tue, 23 Apr 2002, Jing Zhou wrote:
> Date: Tue, 23 Apr 2002 18:09:33 -0500
> From: Jing Zhou <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Another way to find mapped properties
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> 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 <ji...@netspread.com>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > To: Struts Developers List <st...@jakarta.apache.org>
> > > 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
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 <ji...@netspread.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another way to find mapped properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 23 Apr 2002, Jing Zhou wrote:
> Date: Tue, 23 Apr 2002 13:29:40 -0500
> From: Jing Zhou <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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 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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>