Having suggested someone look at making a custom property resolver
myself last week, I was thinking about this, and I suspect that EL
is *deliberately* designed not to allow this. It's actually a bad
idea to code all that internal structure of objects into the view,
because it's a poor level of encapsulation. Exposing all that
structure breaks the "Law of Demeter".
In the example below, if a contact's street is needed in the view,
then Contact itself should have a getStreet() accessor - which may
delegate to an Address object *currently*, but then you'd be free
to change that implementation later. And then EL would have no
problem with #{contact[street]}.
-Jonathan.
Mike Kienenberger wrote:
Right, I see now what you're saying and why my answer is not of any help
:-)
Yes, it's entirely determined by the EL. Have you tried reading
through the unified EL spec to see if there's anything helpful in
there? I thought I had older email that dealt with this topic, but
apparently it's the same thing you're basing your question on, so I
doubt it's of any help:
http://www-128.ibm.com/developerworks/java/library/j-facelets/#N103EC
I guess you could create a custom property resolver if you don't find
anything. A property resolver would definitely work, but would
probably be a lot of work.
On 3/20/07, r.stranders <[EMAIL PROTECTED]> wrote:
Your code is correct. I would like to generalize accessing the
properties of
an entity by with facelets using a construct like #{contact[name]} or
#{contact[address.street]}. The former works, the latter gives an
exception.
I don't think this has anything to do with facelets.
--
.....................................................................
Dr Jonathan Harley .
. Email: [EMAIL PROTECTED]
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
