myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mjdenham <mjden...@gmail.com>
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".

Thanks
Martin


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 <mjdenham@gmail.com 
>>>> <mailto:mjdenham@gmail.com>> 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.
>>>>
>>>>
>>>>       
>>>
>>>     
>>
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19413827.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.


Mime
View raw message