Interesting point. But I think that would be no substitution for the valueChangeListener logic, which only has to be processed whenever a ValueChangeEvent registered for that method is fired.
Actually, I didn't ask for practical solutions, because I have a solution for the problem already. I hope that someony can tell me, why the ValueChange event is fired before that Update Model Value Phase. Is there a practical reason, or is it caused by accident? Regards, Matthias > -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Dennis Byrne > Gesendet: Montag, 21. November 2005 19:25 > An: MyFaces Discussion > Betreff: Re: AW: selectOneMenu and valueChangeListener method - method > call always before Update Model Values phase? > > > In the constructor of the backing bean, make it register > itself for the "Invoke Application" phase, therefore letting > you stick whetever java you want right after the update > models phase. > > ---- Original message ---- > >Date: Mon, 21 Nov 2005 18:48:39 +0100 > >From: "Matthias Kahlau" <[EMAIL PROTECTED]> > >Subject: AW: selectOneMenu and valueChangeListener method - > method call always before Update Model Values phase? > >To: "MyFaces Discussion" <[email protected]> > > > >Thanks, > > > >retrieving the new value in the valueChangeListener method > is not the > >problem at all. You can get it with the getNewValue() method > of the > >ValueChangeEvent given as parameter to the > valueChangeListener method even > >more comfortably than by programmatically pulling the value > from the > >UIComponent that corresponds to the selectOneMenu tag. > > > >But I criticized the behavior. When you look at the JSF > Standard Request > >Processing Lifecycle diagram in the JSF specification, > events can be fired > >between most of the phases in the lifecycle. Why can't the > ValueChangeEvent > >be fired between the Update Model Values phase and the > Invoke Application > >phase? This way, it would be possible to do some > computations in the > >valueChangeListener method based on the current model > values... > > > > > >Regards, > >Matthias > > > > > >> -----Ursprungliche Nachricht----- > >> Von: [EMAIL PROTECTED] > >> [mailto:users-return-12620- > [EMAIL PROTECTED] Auftrag > >> von Dennis Byrne > >> Gesendet: Montag, 21. November 2005 18:19 > >> An: MyFaces Discussion > >> Betreff: Re: selectOneMenu and valueChangeListener method - > method call > >> always before Update Model Values phase? > >> > >> > >> Listeners are fired during the process validations phase of > >> the request life cycle - which is right before the update > >> model phase. You can get access to the value however by > >> programmatically pulling the value from the UIComponent > that > >> corresponds to your selectOneMenu tag. > >> > >> ---- Original message ---- > >> >Date: Mon, 21 Nov 2005 17:37:31 +0100 > >> >From: "Matthias Kahlau" <[EMAIL PROTECTED]> > >> >Subject: selectOneMenu and valueChangeListener method - > >> method call always before Update Model Values phase? > >> >To: "Users MyFaces" <[email protected]> > >> > > >> >Hi, > >> > > >> > > >> >I'm using a Tomahawk selectOneMenu with a > >> valueChangeListener method, and I > >> >wonder why this method is always called before the value > >> (value-binding) of > >> >the selectOneMenu is updated, even if I set immediate to > >> false. Is this > >> >behavior correct or intended, respectively? > >> > > >> >I think this is awkward, because I have to update the Bean > >> Property bound to > >> >the selectOneMenu on my own, since I have to invoke a > method > >> in the > >> >valueChangeListener method, which makes some updates based > >> on the current > >> >model values. > >> > > >> > > >> >Regards, > >> >Matthias > >> > > >> > >> Dennis Byrne > > > > Dennis Byrne
