Andrew, Thanks for your help. We are using JSF 1.1 so I don't think the f:setPropertyActionListener solution will work for us. I tried just putting tr:subform around the inputText and now it doesn't update it at all. Perhaps there is a different way to implement my page? The functionality that I am trying to achieve is to use a selectOneChoice component to select a person from a list of persons to edit. Currently, I am using a valueChangeListener in the selectOneChoice to detect when a person is selected and then update the input components with that persons information. This is where I am having the problem. I would like to avoid using the tomahawk solution since the project doesn't currently use tomahawk and I don't really want to add it just for this problem. Is there any way to have the selectOneChoice fire an action event? If I could do that, then I wouldn't need to use the value change listener.
Thanks, Richard On Tue, Jul 8, 2008 at 10:37 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Value change listeners are fired during validation. > > What happens: > > 1) decode > 1a) select one choice decoded - submitted value set > 1b) input text decoded - submitted value set > 2) validation > 2a) select one choice converts submitted value > 2b) select one choice validates value > 2c) select one choice queues value change event (phase = ANY) > 2d) input text converts submitted value > 2e) input text validates value > 2f) input text queues value change event (phase = ANY) > 2g) value change events broadcast > 3) update model > 3a) select one choice updates value > 3b) input text updates value > > As you can see, it is useless to set values in a value change > listeners that have UIInput components updating them. In fact, it is > very dangerous to make any changes during a value change event, > because at that phase, there is absolutely no guarantee that the > updating of the model will ever happen. Therefore if your bean sets a > property and something short circuits the lifecycle, then the > "transaction" is broken. > > I would suggest one of: > 1) use the myfaces tomahawk sandbox valueChangeNotifier that runs > during update, not validation: > http://myfaces.apache.org/sandbox/tlddoc/s/valueChangeNotifier.html > 2) use f:setPropertyActionListener instead of using value change events > 3) use tr:subForm around the controls to make sure that when the > selectOneChoice is submitted, the inputText is not submitted (note > that I don't think that this solution will work for browsers that do > not support AJAX) > > -Andrew > > On Tue, Jul 8, 2008 at 10:14 PM, Richard Yee <[EMAIL PROTECTED]> wrote: >> Hi, >> I'm having a problem updating the value of a inputText component from >> the value change listener of a selectOneChoice component. I have the >> following in my jspx page: >> >> <f:view> >> <tr:document title="Index"> >> <trh:body> >> <tr:form> >> <tr:selectOneChoice id="memberSelect" >> value="#{myBacking.selectValue}" >> valueChangeListener="#{myBacking.changeListener}" >> autoSubmit="true" > >> <tr:selectItem label="Item 1" value="1"/> >> <tr:selectItem label="Item 2" value="2"/> >> <tr:selectItem label="Item 3" value="3"/> >> </tr:selectOneChoice> >> <tr:inputText value="#{myBacking.line2}" label="Line 2:" >> partialTriggers="memberSelect" id="line2"/> >> >> </tr:form> >> </trh:body> >> </tr:document> >> </f:view> >> >> My value change listener in my backing bean is >> public void changeListener(ValueChangeEvent evt) { >> setLine2("XXXX"); } >> } >> When I run the page, if I only change the value of selectOneChoice, >> then "XXXX" gets populated in the input text box as I expected. >> However, if I type something in the inputText component and then >> change the value of the selectOneChoice, the value that I typed >> remains in the input text box. If I then change the value of the >> select box again, then "XXXX" gets populated in the text box. I'm >> wondering why it takes a second time through the value Change Listener >> for the input text component to be updated with the value that is set >> in the listener method. >> >> Thanks for any help or suggestions in advance, >> >> Richard >> >
