Hi,
thanks a lot for the discussion.As Simon mentioned I will use the
getCONSTANT methods approach.
I guess this is the obvious way to do this. It looks ugly, but I guess
newbies to jsf will understand what happens much quicker then the others
approaches.
Due to the fact that from time to time my students will need to work
with this stuff it would be much easer for them.
Regards
Ingo
Craig McClanahan schrieb:
On 2/7/07, *Jesse Alexander (KSFD 121)*
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 SelectItem
(the thing you need inside a UISelectOne or UISelectMany) using
the contents
of FIELDNAME1 on each row as the label, and the contents of
FIELDNAME2 on
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.
hth
Alexander
Craig
