I tired 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#a9962234
Sent from the MyFaces - Users mailing list archive at Nabble.com.
