You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by mjdenham <mj...@gmail.com> on 2008/09/10 13:22:00 UTC
t:selectItems still seems to need a converter
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}" />
</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.
Re: t:selectItems still seems to need a converter
Posted by mjdenham <mj...@gmail.com>.
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
>>>> <ma...@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.
Re: t:selectItems still seems to need a converter
Posted by Simon Kitching <sk...@apache.org>.
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
>>> <ma...@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.
>>>
>>>
>>>
>>
>>
>
>
Re: t:selectItems still seems to need a converter
Posted by mjdenham <mj...@gmail.com>.
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 <mj...@gmail.com> 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 <mjdenham@gmail.com
>> >> <ma...@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-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.
Re: t:selectItems still seems to need a converter
Posted by Cagatay Civici <ca...@gmail.com>.
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 <mj...@gmail.com> 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 <mjdenham@gmail.com
> >> <ma...@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-tp19411254p19412905.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: t:selectItems still seems to need a converter
Posted by mjdenham <mj...@gmail.com>.
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
>> <ma...@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-tp19411254p19412905.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: t:selectItems still seems to need a converter
Posted by Simon Kitching <sk...@apache.org>.
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
> <ma...@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.
>
>
Re: t:selectItems still seems to need a converter
Posted by Cagatay Civici <ca...@gmail.com>.
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 <mj...@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}" />
> </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.
>
>