On 2/7/07, Jesse Alexander (KSFD 121) wrote:
why inject the static part in the EL-expression
just write the custom resolver and have him check whether the property
name resolves to a static-classmember and return it...
You could indeed do that, but then you'd need to figure out how to deal with
the ambiguity cases like what happens if there is a property and a static
constant with the same name. Yah, not likely, but ... the solution I
proposed will only have one possible clash if you happen to have a property
named "static" :-).

We actually had a somewhat analogous scenario with the components that ship
with Java Studio Creator, and NetBeans Visual Web Pack. One of the things
we tried to do was provide a "data binding" abstraction for components
similar in spirit to things like DataSource in ASP.Net, where you can both
shield the component from details of the underlying data representaiton
(something you can do directly with EL customizations), *and* provided a
programmatic API to retrieve "fields" by name, and keep track of a cursor if
the data had list-like behaviors. We called this interface DataProvider for
the single-object case, and TableDataProvider for the list approach.

Along with this, we did provide custom EL resolvers that could do some cute
stuff, where "foo.bar" resolves to a data provider:

#{foo.bar.value['FIELDNAME']} --> gets or sets the underlying value like
a typical PR does
#{foo.bar.items['FIELDNAME1','FIELDNAME2']} --> returns an array of
(the thing you need inside a UISelectOne or UISelectMany) using the
of FIELDNAME1 on each row as the label, and the contents of
each row as the value.

Originally, we left the word "value" out of the first variant (which is
pretty similar to what you are suggesting). The details are vague in my
memory because this was over a year ago, but we ran into some ambiguities
that were difficult to resolve, so it made more sense to add an explicit
pseudo-property name ("value" in this case) -- which also made the
expressions read a little more aesthetically (at least to me :-).

So, I've generally followed the pattern of an explicit pseudo-property name
when I've implemented something similar. In this particular scenario, I
like the fact that it reminds the developer you're really talking to a
static constant here, so don't expect to be able to modify it ... but it's
certainly not required.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 7 | next ›
Discussion Overview
groupusers @
postedFeb 7, '07 at 10:58a
activeFeb 8, '07 at 3:46p



site design / logo © 2018 Grokbase