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.
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19412905.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
