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