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.
>
>

Reply via email to