You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/09/21 06:30:47 UTC
PROPOSAL: Change in Nested and Indexed Property Names Syntax
The current PropertyUtils module interprets property names to be of one
of the following types:
* Simple (reference to a property of the associated bean):
<struts:property name="bean" property="name"/> calls bean.getName().
* Nested (reference to a property that is a bean whose properties are
then consulted):
<struts:property name="bean" property="address.city"/> calls
bean.getAddress().getCity();
* Indexed (reference to a property that is either indexed or has an
array value:
<struts:property name="bean" property="orders[3]"/> calls either
bean.getOrders(3) for indexed, or bean.getOrders() and pulls the
fourth
item for an array based property.
Several people have pointed out that use of the ".", "[", and "]"
delimiter characters in the name of the property (and, therefore in the
name of the corresponding input field on a form) causes problems if you
want to reference that field in client-side JavaScript code, because
these characters are significant in the JavaScript language. That is a
problem generally, and will become one particularly for Struts when we
expand its capabilities to generate client-side validation code.
Consulting the ECMAScript reference, it appears that identifiers (at
least in that language -- I presume its true for JavaScript generally?
-- can contain letters, digits, underscores ("_"), and dollar signs
("$") only. That leaves us pretty limited options in constructing a
property name that looks like a simple reference to JavaScript, but
looks like a nested or indexed reference to Struts. However, the fact
that there are two special characters available lets us use them for
this purpose -- neither is likely to be used in a property name for a
Struts-aware application anyway.
Therefore, I propose that we use the "_" character (instead of ".") to
define nested property access in Struts, and a dollar sign followed by
an integer (instead of an integer in square brackets) to denote indexed
property access. For example:
* "name" stays "name"
* "address.city" becomes "address_city"
* "orders[3]" becomes "orders$3"
* You still can combine nested and indexed: orders$3_billToAddress_city
gets the city property of the bill-to address associated with the
fourth
order (zero-relative indexing).
It's not quite as pretty (from a Java developer's viewpoint, anyway :-),
but it solves the problems of using characters that are significant to
JavaScript.
What do you think?
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Drew Davidson <dr...@running-start.com>.
"Craig R. McClanahan" wrote:
> Drew Davidson wrote:
>
> >
> > Sorry, but I don't really keep up with this list very much - is there an
> > ECMAScript interpreter on the server that is executing these statements
> > (like address.city -> getAddress().getCity())?
> >
>
> No, it doesn't quite work like that.
>
> Struts includes a PropertyUtils.getProperty() method that takes an object (the
> bean) and the "name" of a property to be retrieved, and returns an Object that
> is the value of that property. It uses the Java reflection APIs to figure out
> how to do this. In Struts, this is used (for example) when populating the
> properties of a form bean, or in the form tags when they look up the current
> values of bean properties.
>
> For simple property names like "address", the reflection APIs know how to tell
> me to call getAddress(), so that's easy. For the nested syntax
> ("address.city" the old way, "address_city" the proposed new way), the
> getProperty() method scans the "name" parameter and splits it up.
> Effectively, we do a getAddress() call, and then a getCity() call, parsing our
> way down whatever "name" the calling program specified.
>
> The issue for JavaScript is that the Struts form tags use the property name
> you specify as the name of the corresponding input field (and therefore the
> corresponding request parameter you get back). For non-Javascript use, that
> is no big deal -- you end up with something like this (using the old syntax):
>
> <input type="text" name="address.city" value="Los Angeles">
>
> which works fine. The problem we're trying to solve is, what happens if you
> want to reference this text field with JavaScript? The "." delimiter is
> significant, so you can't just say:
>
> forms["formname"].address.city = "San Francisco"
>
> and have it do the right thing.
>
> Someone else responded that you might be able to work around this (in
> JavaScript) using "id" attributes instead of "name". I have not had a chance
> to look into this yet.
The reason that I ask is that there exists a good way of doing this with the OGNL
package (which is public domain) that includes this kind of graph navigation, plus
a whole lot more. It is pure Java, compatible with Java 1 and 2 and includes ways
of accessing not only navigation paths (i.e. address.city), but methods for
calling methods explicitly, calling static methods and manipulating lists
(projection & selection, index extraction, etc.). My company is currently using
this to great effect in our product and I think it would make a valuable addition
to Struts.
I've attached the description HTML so that you can evaluate it.
- Drew
--
Drew Davidson
Senior Software Engineer
Running Start, Inc.
(520) 547-4307
(520) 547-4339 (fax)
drew@running-start.com
http://www.running-start.com
RE: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Joe Walnes <jo...@wirestation.co.uk>.
>The problem we're trying to solve is, what happens if you
>want to reference this text field with JavaScript? The "." delimiter is
>significant, so you can't just say:
> forms["formname"].address.city = "San Francisco"
But you can say
forms["formname"].elements["address.city"] = "San Fransisco"
-Joe Walnes
Re: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Drew Davidson wrote:
>
> Sorry, but I don't really keep up with this list very much - is there an
> ECMAScript interpreter on the server that is executing these statements
> (like address.city -> getAddress().getCity())?
>
No, it doesn't quite work like that.
Struts includes a PropertyUtils.getProperty() method that takes an object (the
bean) and the "name" of a property to be retrieved, and returns an Object that
is the value of that property. It uses the Java reflection APIs to figure out
how to do this. In Struts, this is used (for example) when populating the
properties of a form bean, or in the form tags when they look up the current
values of bean properties.
For simple property names like "address", the reflection APIs know how to tell
me to call getAddress(), so that's easy. For the nested syntax
("address.city" the old way, "address_city" the proposed new way), the
getProperty() method scans the "name" parameter and splits it up.
Effectively, we do a getAddress() call, and then a getCity() call, parsing our
way down whatever "name" the calling program specified.
The issue for JavaScript is that the Struts form tags use the property name
you specify as the name of the corresponding input field (and therefore the
corresponding request parameter you get back). For non-Javascript use, that
is no big deal -- you end up with something like this (using the old syntax):
<input type="text" name="address.city" value="Los Angeles">
which works fine. The problem we're trying to solve is, what happens if you
want to reference this text field with JavaScript? The "." delimiter is
significant, so you can't just say:
forms["formname"].address.city = "San Francisco"
and have it do the right thing.
Someone else responded that you might be able to work around this (in
JavaScript) using "id" attributes instead of "name". I have not had a chance
to look into this yet.
>
> - Drew
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Drew Davidson <dr...@running-start.com>.
"Craig R. McClanahan" wrote:
> The current PropertyUtils module interprets property names to be of one
> of the following types:
>
> * Simple (reference to a property of the associated bean):
> <struts:property name="bean" property="name"/> calls bean.getName().
>
> * Nested (reference to a property that is a bean whose properties are
> then consulted):
> <struts:property name="bean" property="address.city"/> calls
> bean.getAddress().getCity();
>
> * Indexed (reference to a property that is either indexed or has an
> array value:
> <struts:property name="bean" property="orders[3]"/> calls either
> bean.getOrders(3) for indexed, or bean.getOrders() and pulls the
> fourth
> item for an array based property.
>
> Several people have pointed out that use of the ".", "[", and "]"
> delimiter characters in the name of the property (and, therefore in the
> name of the corresponding input field on a form) causes problems if you
> want to reference that field in client-side JavaScript code, because
> these characters are significant in the JavaScript language. That is a
> problem generally, and will become one particularly for Struts when we
> expand its capabilities to generate client-side validation code.
>
> Consulting the ECMAScript reference, it appears that identifiers (at
> least in that language -- I presume its true for JavaScript generally?
> -- can contain letters, digits, underscores ("_"), and dollar signs
> ("$") only. That leaves us pretty limited options in constructing a
> property name that looks like a simple reference to JavaScript, but
> looks like a nested or indexed reference to Struts. However, the fact
> that there are two special characters available lets us use them for
> this purpose -- neither is likely to be used in a property name for a
> Struts-aware application anyway.
>
> Therefore, I propose that we use the "_" character (instead of ".") to
> define nested property access in Struts, and a dollar sign followed by
> an integer (instead of an integer in square brackets) to denote indexed
> property access. For example:
>
> * "name" stays "name"
>
> * "address.city" becomes "address_city"
>
> * "orders[3]" becomes "orders$3"
>
> * You still can combine nested and indexed: orders$3_billToAddress_city
>
> gets the city property of the bill-to address associated with the
> fourth
> order (zero-relative indexing).
>
> It's not quite as pretty (from a Java developer's viewpoint, anyway :-),
> but it solves the problems of using characters that are significant to
> JavaScript.
>
> What do you think?
Sorry, but I don't really keep up with this list very much - is there an
ECMAScript interpreter on the server that is executing these statements
(like address.city -> getAddress().getCity())?
- Drew
--
Drew Davidson
Senior Software Engineer
Running Start, Inc.
(520) 547-4307
(520) 547-4339 (fax)
drew@running-start.com
http://www.running-start.com
Re: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Luis Arias <lu...@elysia.com>.
Craig,
I hope I'm not too late to participate in this discussion... I've haven't
been able to devote the time that I would like to struts lately ... :-(
But, I'll be back the next few nights and on Friday !
Anyway, I just wanted to suggest that the current syntax simply be mapped
to the proposed syntax dynamically by the different tags (a kind of name
mangling). This way
developers could continue to use current syntax which is nice and clean and
javascript could be generated by struts or be written by hand using the
proposed syntax as long as the mapping rules are clearly documented.
Luis.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, September 21, 2000 6:30 AM
Subject: PROPOSAL: Change in Nested and Indexed Property Names Syntax
> The current PropertyUtils module interprets property names to be of one
> of the following types:
>
> * Simple (reference to a property of the associated bean):
> <struts:property name="bean" property="name"/> calls bean.getName().
>
> * Nested (reference to a property that is a bean whose properties are
> then consulted):
> <struts:property name="bean" property="address.city"/> calls
> bean.getAddress().getCity();
>
> * Indexed (reference to a property that is either indexed or has an
> array value:
> <struts:property name="bean" property="orders[3]"/> calls either
> bean.getOrders(3) for indexed, or bean.getOrders() and pulls the
> fourth
> item for an array based property.
>
> Several people have pointed out that use of the ".", "[", and "]"
> delimiter characters in the name of the property (and, therefore in the
> name of the corresponding input field on a form) causes problems if you
> want to reference that field in client-side JavaScript code, because
> these characters are significant in the JavaScript language. That is a
> problem generally, and will become one particularly for Struts when we
> expand its capabilities to generate client-side validation code.
>
> Consulting the ECMAScript reference, it appears that identifiers (at
> least in that language -- I presume its true for JavaScript generally?
> -- can contain letters, digits, underscores ("_"), and dollar signs
> ("$") only. That leaves us pretty limited options in constructing a
> property name that looks like a simple reference to JavaScript, but
> looks like a nested or indexed reference to Struts. However, the fact
> that there are two special characters available lets us use them for
> this purpose -- neither is likely to be used in a property name for a
> Struts-aware application anyway.
>
> Therefore, I propose that we use the "_" character (instead of ".") to
> define nested property access in Struts, and a dollar sign followed by
> an integer (instead of an integer in square brackets) to denote indexed
> property access. For example:
>
> * "name" stays "name"
>
> * "address.city" becomes "address_city"
>
> * "orders[3]" becomes "orders$3"
>
> * You still can combine nested and indexed: orders$3_billToAddress_city
>
> gets the city property of the bill-to address associated with the
> fourth
> order (zero-relative indexing).
>
> It's not quite as pretty (from a Java developer's viewpoint, anyway :-),
> but it solves the problems of using characters that are significant to
> JavaScript.
>
> What do you think?
>
> Craig McClanahan
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
>
>
Re: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Chris Miller <ki...@vardus.com>.
Hi Craig,
First of all, let me thank you for the detailed explanation of how things
*currently* work - I would love to see this put into the documentation
(apologies if it's there - I looked a couple of weeks back and didn't see
anything).
As for the suggested changes, they sound fine, however can I suggest that
you also leave in the . and [] characters, since a developer that doesn't
care about Javascript will probably consider them to be more intuitive and
easy on the eyes (plus you'd keep backwards compatibility).
This might mean it would be easier to use orders[3] and orders$3$, since
parsing would become a fraction easier (although I like orders$3 better).
My 2 cents.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, September 21, 2000 5:30 AM
Subject: PROPOSAL: Change in Nested and Indexed Property Names Syntax
> The current PropertyUtils module interprets property names to be of one
> of the following types:
>
> * Simple (reference to a property of the associated bean):
> <struts:property name="bean" property="name"/> calls bean.getName().
>
> * Nested (reference to a property that is a bean whose properties are
> then consulted):
> <struts:property name="bean" property="address.city"/> calls
> bean.getAddress().getCity();
>
> * Indexed (reference to a property that is either indexed or has an
> array value:
> <struts:property name="bean" property="orders[3]"/> calls either
> bean.getOrders(3) for indexed, or bean.getOrders() and pulls the
> fourth
> item for an array based property.
>
> Several people have pointed out that use of the ".", "[", and "]"
> delimiter characters in the name of the property (and, therefore in the
> name of the corresponding input field on a form) causes problems if you
> want to reference that field in client-side JavaScript code, because
> these characters are significant in the JavaScript language. That is a
> problem generally, and will become one particularly for Struts when we
> expand its capabilities to generate client-side validation code.
>
> Consulting the ECMAScript reference, it appears that identifiers (at
> least in that language -- I presume its true for JavaScript generally?
> -- can contain letters, digits, underscores ("_"), and dollar signs
> ("$") only. That leaves us pretty limited options in constructing a
> property name that looks like a simple reference to JavaScript, but
> looks like a nested or indexed reference to Struts. However, the fact
> that there are two special characters available lets us use them for
> this purpose -- neither is likely to be used in a property name for a
> Struts-aware application anyway.
>
> Therefore, I propose that we use the "_" character (instead of ".") to
> define nested property access in Struts, and a dollar sign followed by
> an integer (instead of an integer in square brackets) to denote indexed
> property access. For example:
>
> * "name" stays "name"
>
> * "address.city" becomes "address_city"
>
> * "orders[3]" becomes "orders$3"
>
> * You still can combine nested and indexed: orders$3_billToAddress_city
>
> gets the city property of the bill-to address associated with the
> fourth
> order (zero-relative indexing).
>
> It's not quite as pretty (from a Java developer's viewpoint, anyway :-),
> but it solves the problems of using characters that are significant to
> JavaScript.
>
> What do you think?
>
> Craig McClanahan
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
>
>
>
RE: PROPOSAL: Change in Nested and Indexed Property Names Syntax
Posted by Joe Walnes <jo...@wirestation.co.uk>.
Craig, some observations:
Elements can have any name whatsoever and still be accessed via
ECMA/JavaScript, using a quoted string instead. eg:
document.myform.someelement can also be accessed as
document.forms['myform'].elements['someelement']. Having Java-like names
does not cause a problem for ECMA/JavaScript.
A Java indentifier *can* have a property named 'orders$3_billToAddress_city'
(as $ and _ are legal characters). However, 'order[3].billToAddress.City'
cannot be confused with an identifier.
Client-side scripting languages can change. Suppose (completely
hypothetically) PerlScript wanted to be used on the client-side instead, the
$ character would then pose a problem. Ok, that's kindof irrelevant, but I'm
just illustrating why ECMA/JavaScript naming conventions should not be
posing restrictions.