Thanks so much for this. My long-standing annoyance where validation errors were appearing after autoSubmits is now solved, and I understand why (even better!)
Well, almost. There is one other case where validation errors are still appearing where they shouldn't: When I click on a nav link (commandMenuItem inside my menuTree). I want it to bypass validations, so I set immediate to true on the link According to http://www-128.ibm.com/developerworks/library/j-jsf3/, That should make the action method fire before validations. Apparently not. Validation errors still appear. I tried putting renderResponse() in my action method to force it to quit the lifecycle hopefully before validations. No luck. I thought I use the same trick as before: make the link immediate and put the logic in a valueChangeListener and use renderResponse in the listener (I know that avoids validations), but I don't know how to return a JSF outcome from a valueChangeListener. I feel like I'm heading farther and farther down the road of ugly hacks. Is making the commandMenuItem immediate sufficient to avoid validations? Thanks Dan -----Original Message----- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 7:25 PM To: [email protected] Subject: Re: partialTriggers not updating 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 > > >
