The sandbox component doesn't do what you want anyway. It's all server-side, not client-side.
On 4/12/07, monkeyden <[EMAIL PROTECTED]> wrote:
monkeyden wrote: > > "I know Tomahawk has something like this in the sandbox. We're using > ICEFaces but I think this is a standard JSF question." > I'm not switching for one control. I've programmatically updated the backing bean's List<SelectItem>. All I need to know is how to tell JSF to update the values, for this component, from the backing bean. I want to do this within a value change listener method. Beelen, Marco wrote: > > With the risk of stating the obvious: > > Have you taken a look at: > http://myfaces.apache.org/sandbox/selectManyPicklist.html > It does the trick for me perfectly! > > With regards, > Marco > > -----Original Message----- > From: monkeyden [mailto:[EMAIL PROTECTED] > Sent: donderdag 12 april 2007 4:45 > To: [EMAIL PROTECTED] > Subject: Re: Programatically updating the model > > > > 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:availa > bleLocations', > 'advancedPropertySearch:advPropTabSet:userLocations');return false;" > /> > Remove Button > <ice:commandButton value="#{messages['propertysearch.button.remove']}" > > onclick="removeSelectedOptions('advancedPropertySearch:advPropTabSet:use > rLocations', > '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:advPropTab > Set: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-cla > ss> >> </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</rendere > r-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. > > > > > ------------------------------------------------------------------------------ > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, > New Jersey, USA 08889), and/or its affiliates (which may be known > outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD > and in Japan, as Banyu - direct contact information for affiliates is > available at http://www.merck.com/contact/contacts.html) that may be > confidential, proprietary copyrighted and/or legally privileged. It is > intended solely for the use of the individual or entity named on this > message. If you are not the intended recipient, and have received this > message in error, please notify us immediately by reply e-mail and then > delete it from your system. > > ------------------------------------------------------------------------------ > > -- View this message in context: http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9959591 Sent from the MyFaces - Users mailing list archive at Nabble.com.
