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 <[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-tp19411254p19413827.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
