myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: Programatically updating the model
Date Thu, 12 Apr 2007 14:53:33 GMT
Use the following to put a component into a state where it should
fetch values from the backing bean model:

     component.setSubmittedValue(null);
     component.setLocalValueSet(false);


On 4/12/07, monkeyden <monkeyden@gmail.com> wrote:
>
> Isn't there a simple way to tell JSF to ask the backing bean for the
> SelectList again, after I've matched it with the submitted values in the
> VCL?  I tried setLocalValueSet(false), in hopes that it would tell JSF that
> the local value needs to be updated.  Not sure if this is the right method
> as the javadoc only says:
>
> Sets the "local value set" state for this component.
>
>
> Mike Kienenberger wrote:
> >
> > Ah,  I didn't really think you were using client-side javascript.
> > Yes, if you're using javascript to move the stuff around, then it's a
> > different story.
> >
> > Yes, overriding a renderer (or component if that works) would change
> > the behavior for the entire application.   What you'd probably want to
> > do is create a new tag for this use case.   In facelets, this is
> > trivial -- just add another tag-to-namespace-to-component-to-renderer
> > mapping.   I'm not sure how complicated it would be using jsp.   Maybe
> > you can simply add another tld entry.   Or you might have to create a
> > new JSP tag handler class as well (but you can simply subclass the
> > existing one, I'd think).
> >
> > So the two choices I see that you'd have are to override the
> > validateValues method in the component or to pass both List A and List
> > B value sets to the component/renderer, and change the renderer not to
> > render one set of values which would allow the component to use both
> > sets for value validation.
> >
> > Three if you count creating your own component from scratch -- not
> > sure if you'd gain enough by doing this.
> >
> >
> > On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > Are you physically moving with javascript the values 1,2,3 over to the
> >> > other html element form data?
> >> >
> >> I'm physically moving the values using JavaScript.
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > Or when you submit the form, are you submitting values 1,2,3 for List
> >> > A, submitting no values for List B, and executing a move action (or
> >> > action listener)?   This is what would normally happen if you had two
> >> > SelectMany components and a button on a page.
> >> >
> >> I assume you're referring to submission when the Add/Remove buttons are
> >> clicked.  For better or worse (most likely worse), everything is client
> >> side
> >> until the form is submitted.  The Direct-to-DOM feature of ICEFaces would
> >> be
> >> great for this if list A didnt potentially have 400+ items.  This
> >> absolutely
> >> kills performance.
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > The validation for List B should happen when List B still has no
> >> > elements.  Maybe validation is failing because you told it that List B
> >> > requires a value?
> >> >
> >> I have required="false" for the component.  In fact, here is the code:
> >>
> >> List A
> >> <ice:selectManyListbox id="availableLocations" required="false"
> >>     size="11" styleClass="inputText" style="width:200px"
> >> ondblclick="NEMAdd();return false;" immediate="true">
> >>     <f:selectItems value="#{advancedSearchAction.availableTowns}" />
> >> </ice:selectManyListbox>
> >>
> >> Add Button
> >> <ice:commandButton value="#{messages['propertysearch.button.add']}"
> >>
> >> onclick="addSelectedOptions('advancedPropertySearch:advPropTabSet:availableLocations',
> >> 'advancedPropertySearch:advPropTabSet:userLocations');return false;"
> >> />
> >> Remove Button
> >> <ice:commandButton value="#{messages['propertysearch.button.remove']}"
> >>
> >> onclick="removeSelectedOptions('advancedPropertySearch:advPropTabSet:userLocations',
> >> 'advancedPropertySearch:advPropTabSet:availableLocations');return false;"
> >> />
> >>
> >> List B
> >> <ice:selectManyListbox immediate="true" id="userLocations" size="11"
> >> styleClass="inputText" style="width:200px" required="false"
> >>     value="#{advancedSearchAction.submittedTowns}"
> >>
> >> ondblclick="removeSelectedOptions('advancedPropertySearch:advPropTabSet:userLocations',
> >> 'advancedPropertySearch:advPropTabSet:availableLocations');return
> >> false;">
> >>     <f:selectItems value="#{advancedSearchAction.selectedTowns}" />
> >> </ice:selectManyListbox>
> >>
> >> And, last but not least, the button which submits:
> >> <ice:commandButton id="searchNowA"
> >>
> >> onclick="processLocations();selectAll('advancedPropertySearch:advPropTabSet:userLocations',
> >> 0);selectAll('advancedPropertySearch:advPropTabSet:availableLocations',
> >> 0);"
> >>     value="#{messages['propertysearch.label.button.searchNow']}"
> >>     action="#{advancedSearchAction.search}"
> >> />
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > Are you sure that validation isn't failing for some other reason than
> >> > the one you think?  Put some messages tags on your page.
> >> >
> >> I'm positive.
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > As for subclassing, you can add things like this to your
> >> faces-config.xml
> >> > file.
> >> >
> >> >       <component>
> >> >
> >> >
> >> <component-type>com.xyz.jsf.component.PropertyComparator</component-type>
> >> >
> >> >
> >> <component-class>com.xyz.jsf.component.PropertyComparator</component-class>
> >> >       </component>
> >> >
> >> >       <render-kit>
> >> >         <render-kit-id>HTML_BASIC</render-kit-id>
> >> >
> >> >         <renderer>
> >> >
> >> <component-family>org.apache.myfaces.Radio</component-family>
> >> >             <renderer-type>org.apache.myfaces.Radio</renderer-type>
> >> >
> >> >
> >> <renderer-class>com.xyz.jsf.component.ExtendedHtmlRadioRenderer</renderer-class>
> >> >         </renderer>
> >> >
> >> >     </render-kit>
> >> >
> >> > I know for sure that overriding a renderer works this easily.
> >> >
> >> Doesn't this setting extend this method for all occurances of
> >> "org.apache.myfaces.Radio" in your application?
> >>
> >>
> >> Mike Kienenberger wrote:
> >> >
> >> > I don't know for sure that overriding a component works in standard
> >> > JSF/JSP.   It'd be easy to test.
> >> >
> >> > I know that in Facelets, you can trivially redefine a new tag name
> >> > with a different component and renderer.
> >> >
> >> >     <tag>
> >> >         <tag-name>dataTable</tag-name>
> >> >         <component>
> >> >
> >> > <component-type>org.apache.myfaces.HtmlDataTable</component-type>
> >> >             <renderer-type>org.apache.myfaces.Table</renderer-type>
> >> >         </component>
> >> >     </tag>
> >> >
> >> > Worse case, you might need to also define a new tld/jsp TagHandler.
> >> >
> >> On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
> >> >
> >> > Here is why I believe I need to do this...correct me if Im wrong.
> >> >
> >> > I have two lists (A and B).  List A has values 1,2,3,4,5 .  List B has
> >> > nothing.  I move the values 1,2,3 over to list B and submit.  Because
> >> the
> >> > values 1,2,3 are not a subset of the original <f:selectItems> used
to
> >> > populate list B, the submitted values are invalid.
> >> >
> >> > I can't get to the "update model phase" because the component has
> >> already
> >> > failed validation in the previous phase.  I would like to know about
> >> > extending UISelect, mainly how to tell JSF to use my subclass.  I've
> >> never
> >> > extended JSF in this manner.
> >> >
> >> > Thanks for the response.
> >> >
> >> >
> >> > Mike Kienenberger wrote:
> >> > >
> >> > > Would it be easier for you to override the following method in
> >> > > UISelect in your own component subclass?
> >> > >
> >> > > protected void validateValue(FacesContext context, Object
> >> > convertedValue)
> >> > >
> >> > > I'm actually kind of confused why you'd even need to do this.
> >> > >
> >> > > Your source select many component has a list of items, and any items
> >> > > you select in it should be valid.   The same should be true for your
> >> > > destination component.
> >> > >
> >> > > You would update the lists after the update model phase (invoke
> >> > > action) and before rendering a new response, so there shouldn't be
> >> any
> >> > > trickery necessary.
> >> > >
> >> > > I do something similar with two UIData components and two lists. 
 My
> >> > > "picker" only works for one item at a time, but should be pretty much
> >> > > the same other than that.
> >> > >
> >> > >
> >> > > On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
> >> > >>
> >> > >> I'm implementing a "mover box control", which consists of two
select
> >> > >> boxes
> >> > >> and two mover buttons (Add/Remove).
> >> > >> In the valueChangeListener method,  I need to programmatically
take
> >> the
> >> > >> submitted values and create SelectItems out of them.  In order
to
> >> trick
> >> > >> JSF
> >> > >> into thinking that they are valid, I'd like to update the model.
> >> This
> >> > is
> >> > >> done to get around the problem of submitted values not being valid
> >> when
> >> > >> they
> >> > >> are not a subset of the original list.  I've tried several of
the
> >> > methods
> >> > >> on
> >> > >> UIInput and UIViewRoot but none seem to be working correctly.
 I
> >> know
> >> > >> Tomahawk has something like this in the sandbox.  We're using
> >> ICEFaces
> >> > >> but I
> >> > >> think this is a standard JSF question.
> >> > >>
> >> > >> Thanks for the guidance
> >> > >> --
> >> > >> View this message in context:
> >> > >>
> >> >
> >> http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9949895
> >> > >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >> http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9951617
> >> > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9952049
> >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9960947
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>

Mime
View raw message