myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: t:selectItems still seems to need a converter
Date Wed, 10 Sep 2008 12:14:19 GMT
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.
>
>


Mime
View raw message