I tried the partialSubmit attribute in ICEFaces (server-side control with Ajax updates to the client), which works nicely for text fields, radios, checkboxes and small to medium sized select lists. Mine were too large (400-500 items) so it dragged. It works exactly as I would expect (only sending updates for components to the client). The problem is the "update" for this one component is significant. It actually send the <select> tag and 400-500 <option> tags.
Mike Kienenberger wrote: > > 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. >> >> > > -- View this message in context: http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9960883 Sent from the MyFaces - Users mailing list archive at Nabble.com.
