Anyone else have any ideas on how to get around this? In a
valueChangeListener method, I update the list bound to a UISelectMany and I
want to tell JSF to update the UISelectMany from the backing bean before
validating.
monkeyden wrote:
>
> I tried this. The component still fails validation, so JSF still has the
> old version of the list.
>
>
> Mike Kienenberger wrote:
>>
>> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9982567
Sent from the MyFaces - Users mailing list archive at Nabble.com.
