Sorry, my example was quite poor. I was thinking of instances when
setPropertyActionListener is used with lists of items and one specific
object from the list has to be selected before assignment e.g.
<rich:dataTable value="#{allPartsList}" var="part">
<rich:column>
<h:outputText value="#{part.name}"/>
</rich:column>
<rich:column>
<h:commandButton value="Select" action="#{order.send}">
<f:setPropertyActionListener value="#{part}"
target="#{order.carPart}" />
</h:commandButton>
</rich:column>
</rich:dataTable>
So the above starts with a list i.e. allPartsList and ends up with one list
item from the original list being selected and assigned which seems to be
similar to what a SelectOneMenu should do but it is a DataTable.
I don't understand how clicking a button in a DataTable finds the correct
object but selecting an item in a selectOneMenu can only find the id of the
selected object and not the object itself.
Regards
Martin
Cagatay Civici wrote:
>
> SetPropertyActionListener is a different case, it just resolves the part
> and
> assigns it to order.carPart when a command is executed.
>
> If not immediate, actionlisteners are fired at invoke application phase
> and
> at this point any type of conversion is already completed.
>
> So actually setPropertyActionListener does not know about html.
>
> On Wed, Sep 10, 2008 at 8:51 AM, mjdenham <[EMAIL PROTECTED]> wrote:
>
>>
>> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19413744.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
