OK, well here's one more bit of fun: you can't just update the backing bean and have components refresh. You need to call UIXEditableValue.resetValue() on each component too, to get them to forget the submitted value and go back to the model. Basically, the same code that is helping you redisplay incorrect values when validation fails is here getting in the way.
In JSF 1.2, the invokeOnComponent() API will give us some much better ways around this problem by limiting the lifecycle of the original autoSubmit. -- Adam On 1/9/07, Daniel Hannum <[EMAIL PROTECTED]> wrote:
I have an autoSubmit field and in its valueChangeListener, I update a whole bunch of other fields on a page. In order to get around validation problems (recently discussed), I did what Adam implied earlier today: put immediate="true" on the component and then use renderResponse() in the listener. Makes sense that that would do what I want, given my understanding of the lifecycle: (avoid validations and go directly to redisplaying the new data) Unfortunately, all is not well. My handler changes all the backing bean class members tied to the components (just strings, nothing fancy), and all the components are set with partialTriggers="theAutoSubmitComponent". Seems simple I see in the debugger that the fields are being changed in the listener, but the fields are never updated on the UI. The old data is still there. Worse, when I eventually submit the form, JSF goes through the Update Model Values phase and changes my backing bean members BACK to the old incorrect values. I'm not sure what's wrong. Is changing the backing members insufficient. Do I also have to change the internal value of the component (as described here: http://groundside.com/blog/DuncanMills.php?title=when_ppr_doesn_t_see_to _work&more=1&c=1&tb=1&pb=1) Does short-circuiting the lifecycle as I described above prevent partialTriggers from firing? When does it fire? Any help is appreciated. Thanks Dan
