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.
