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" <Craig.McClanahan@eng.sun.com>
To: <struts-dev@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
>
>
>
|