myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mjdenham <>
Subject Re: t:selectItems still seems to need a converter
Date Wed, 10 Sep 2008 13:39:14 GMT

Apologies, I posted my previous e-mail before reading this.  Yes I agree it
would be a nice enhancement if select components were to support
select-values being indexes into a "data model".


Simon Kitching wrote:
> 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 < 
>>>> <>> 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="#{ <>}" />
>>>>     </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:
>>>>     Sent from the MyFaces - Users mailing list archive at

View this message in context:
Sent from the MyFaces - Users mailing list archive at

View raw message