Simon, right, right, double right.
Same request lifecycle. Just one action event is possible on each request. regards, Martin On 11/16/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Dennis Byrne wrote: > > I have questions regarding when @value is read and when > > @property is set. > > > > Does @value get read during request cycle n - and then > > @property is set during the request cycle n+1 ? This would > > make it even more useful than t:saveState because the 'to' > > and 'from' don't have to be the same place. Or does the read > > and write occur during the same request cycle? > > > > Also, during which phases do these events occur? > > From the code I can see that both the read and write occur in the > processEvent callback. So everything happens at whatever phase the > associated component's ActionEvent is processed. > > All UICommand components (buttons, links) fire their event during the > invokeApplication phase, unless their immediate flag is set [I think]. > > I expect the typical usecase is the updateActionListener setting a > property, then the link/button action navigating to another page whose > backing bean reads that property. In this setup there is no problem with > actionListener ordering. > > Can more than one action event fire during a single post? I presume not. > If they can there might be interesting timing issues. > > It sounds to me like your cross-request processing would be an > enhancement to t:saveState than an enhancement to updateActionListener. > UpdateActionListener is pretty simple and clean. > > > Regards, > > Simon > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
