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.

Reply via email to