Hi Martin,
Unfortunately this is not the same situation.
A setPropertyActionListener is simply attached to a command component.
And a command-component is simply either "triggered" or "not triggered".
When the command-component is triggered, the listeners run. The
setPropertyActionListener reads its value attribute and writes to its
target attribute; neither the command component nor the listener keep
maps of backing objects or anything similar. Even within a table, this
is what happens. However in that case, the value attribute will point at
the "var" variable of the table, and it is the table that magically sets
that up appropriately to point to the right row-object.
Actually, the implementation of table is somewhat like my suggestion
below for rendering a list "index" as the select value. The table does
indeed simply assume that row1 of the data posted back matches row1 of
the object-list held by the backing bean. So it could be argued that
having Select components support select-values being indexes into a
"data model" is reasonable and consistent with table behaviour. But
certainly nothing like that is implemented at the moment.
Regards,
Simon
mjdenham schrieb:
I see what you are saying. However there do seem to be some components/tags
which handle object mapping automagically e.g.
<f:setPropertyActionListener value="#{part}" target="#{order.carPart}" />
I realise that tags like setPropertyActionListener are not used with
selectOneMenu/selectItems but it is used with other lists e.g. tables, and I
wonder that if setPropertyActionListener can keep a map between html values
and backing objects then maybe it could be done elsewhere.
Kind regards
Martin
Simon Kitching wrote:
Hi,
JSF must send down to the browser a list of (label,value) pairs for the
user to select from, and then on postback the browser sends back the
value part of the selected item. The label and value must both be
strings; this is required by html. Therefore a converter of some sort is
definitely needed in order to generate appropriate "value" strings for
the items when rendering the page, and on postback the renderer must be
able to map back from the selected "value" to the appropriate item object.
Doing this conversion automatically is clearly not possible, so an
appropriate converter must be provided. For the case where the items to
be selected from are persistent entities, the converter should generally
write out the "key" of the object, and on postback retrieve the object
using the key.
Maybe one option is for the select* components on render to use the
index into the list of items as the value. Then on postback, as long as
the same list of objects is available then it could map back from index
to object. This would need some more thought though; for example this is
valid:
<h:selectOneMenu>
<f:selectItem ..>
<f:selectItems ..>
<f:selectItem ..>
</h:selectOneMenu>
which would complicate computing an index. And I think this
functionality would need to be in the t:selectOneMenu etc, as the
t:selectItems component is only used at render time, and is not used to
process the postback data AFAIK. Or this idea may be complete rubbish; I
haven't thought about it for long..
As Cagatay says, you can register a "global" converter for each of your
persistent classes within a faces-config.xml file. Then it will be used
automatically rather than you having to define the converter within each
t:selectItems or f:selectItems tag.
Regards,
Simon
Cagatay Civici schrieb:
Conversions are the nature of jsf so it really makes sense to use a
converter for t:selectItems.
Generally the common solution is two write a generic jpa entity
converter if you are using jpa with jsf.
Using the converter-for-class kinda config once, you dont need to
define the converter each time you use it.
On Wed, Sep 10, 2008 at 7:22 AM, mjdenham <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I was wondering if t:selectItems could be enhanced to work without a
converter because it has the list of all the domain objects.
My code is similar to this:
<h:selectOneMenu value="#{order.carPart}">
<t:selectItems value="#{carParts}" var="part" itemValue="#{part}"
itemLabel="#{part.name <http://part.name>}" />
</h:selectOneMenu>
public class Order {
private CarPart carPart;
...
}
t:selectItems automatically generates SelectItem objects for us
but it would
be nice if it also allowed objects to be assigned to the actual
selectOneMenu e.g. order.carPart value without requiring a
Converter. Is it
possible?
I tried and get a null Converter error.
Thanks
Martin
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19411254.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
