myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volker Weber" <v.we...@inexso.de>
Subject Re: JSF Lifecycle Question
Date Wed, 26 Mar 2008 11:01:13 GMT
Hi, see inline

2008/3/25, simon <simon.kitching@chello.at>:
> Hmm.interesting.
>
>  In this case, I think your radio-button has absolutely no effect on your
>  program (although that still doesn't explain why the textbox is empty).
>
>  I believe the process is like this:
>
>  on postback:
>  (restore view phase)
>   * the view (component tree) is restored
>  (update values phase)
>   * the radio button component pulls its settings from the posted data
>   * the textbox component pulls its settings from the posted data
>   * the commandButton sees it has been activated and queues an event
>  (convert and validate phases apply)
>  (update model phase)
>   * the radio button updates the backing bean, and clears its
>    submitted state
>   * the textbox updates the backing bean and clears its
>    submitted state

Here is the problem: the textbox did NOT update the backingBean and
did NOT clear the submitted state because the value of the rendered
attribute evaluates to false after the radioButton has updated the
bean!

if you switch the order of textbox and radio button it should work as expected.


>  (invoke application phase)
>   * the queued events are run, causing the backing bean to be deleted
>  (render phase)
>   * some EL expression causes a new backing bean instance to be
>    created
>   * the textbox calls the backing bean to check its rendered state [1]
>   * assuming the textbox is rendered, it calls the backing bean to get
>    the value to render
>   * etc for all other components
>
>  [1] At this point, the backing bean has completely thrown away the data
>  the radio-button set, so the rendered state for the textbox is reset to
>  whatever is the default for the backing bean.
>
>  Although [1] above is probably not what you wanted, it still does not
>  explain the textbox problem.
>
>  Questions:
>  (1) are you returning a string from the button action listener method,
>  or null? Returning a string can cause a fresh view tree to be created.
>  You *probably* want to return null here, but in either case I cannot see
>  it causing the problem you see.
>
>  (2) are you using component bindings anywhere? Bindings can have all
>  sorts of odd side-effects, and are better avoided where possible.
>
>  (3) is the value setter method for the textbox being called (during the
>  apply-values phase)? If it is, then the textbox will definitely be
>  clearing its cached "submitted value". If it is not, then that would
>  explain the problem - although I cannot see why it would *not* be
>  called...
>
>  (4) is the method for the textbox rendered property being called *during
>  the render phase*? I presume it is, but it might be nice to check..
>
>  Hmm..it just occurred to me that during the apply-values phase, a
>  component only pulls data from the submitted form *if it is rendered*.
>  Otherwise, it is just a waste of time; the component was never in the
>  form so there will of course be no data to fetch from the posted form.
>  And it figures out whether it was rendered by evaluating its rendered
>  expression. Now there *should* be no conflict with the fact that the
>  radio button changes this status, because the radio button only pushes
>  its state into the backing bean later (in update-model) but it's
>  something to think about. I certainly hope that components do not check
>  their rendered state during the "update model" phase...
>
>  You might also try to create a very simple webapp that demonstrates the
>  problem, then try a more recent myfaces/tomahawk release.
>
>  Otherwise, I'm puzzled. Sorry.
>
>
>  And by the way, when someone replies to an email with "bottom-posting"
>  style, it is a bit rude to then add your comments in "top-posting
>  style". It also makes the thread hard to read.
>
>  Regards, Simon
>
>
>
>
>  On Tue, 2008-03-25 at 11:48 -0700, mjovanov wrote:
>  > Hi Simon, thanks for your response. As I mentioned in my original posting,
>  > the Reset button is a command button and is bound to an action listener
>  > method;  as I understand, this method is invoked during the
>  > invoke-application phase and it deletes the backing bean, so I don't think I
>  > am bypassing the apply-values phase. I don't have the immediate attribute on
>  > the Reset button.
>  >
>  > You pose a very good question in the last paragraph: as I understand, what
>  > takes place then is that, in the render-response, JSF is forced to
>  > re-instantiate the backing bean (so that it can provide the state back to
>  > all the components) and this is when a constructor is invoked.  This works
>  > for all the other components, which then get their values from the database
>  > except for the text box (the getter is never called!). The only thing unique
>  > about the text box is that is was not rendered in the previous request
>  > (because the radio button had a different value than what's in the
>  > database).
>  >
>  >
>  > simon.kitching@chello.at wrote:
>  > >
>  > >
>  > > On Tue, 2008-03-25 at 08:32 -0700, mjovanov wrote:
>  > >> There is a radio button and a text box on a page. The radio button
>  > >> controls whether the text box is rendered or not. There is also a
>  > >> Reset button, which I have coded to simply remove the backing bean
>  > >> from the session scope thus forcing the constructor to be called
>  > >> (which then loads data from the database). If, however, the value for
>  > >> the radio button from the database calls for the text box to be
>  > >> rendered, I find that the text box is indeed rendered but without any
>  > >> contents, even though there is some in the database. I am guessing
>  > >> this is because JSF after each phase checks whether a component is to
>  > >> be rendered or not and, if it's not, it then removes all its queued
>  > >> events; as a result, the getter for the value bind to the text box is
>  > >> not called. I wish JSF would not do this…can anyone suggest an elegant
>  > >> solution to this problem? I am using MyFaces 1.1.4 and Tomahawk
>  > >> 1.1.3.
>  > >
>  > > I don't think your analysis is quite right. Queued events can affect the
>  > > update-model and apply-request-values parts of the lifecycle, but I
>  > > cannot think of any events that affect the rendering phase.
>  > >
>  > > During the render phase, components like h:inputText do:
>  > > * if this component has a "submitted value" that was provided during the
>  > > form post, but the update-model did not run, then re-display that
>  > > "submitted value"
>  > > * else evaluate the value expression to fetch a value from the model.
>  > >
>  > > So I suspect what has happened is that you are bypassing the
>  > > apply-values phase for the text box, and so rendering the cached value
>  > > (a blank string). You aren't using "immediate" anywhere are you?
>  > >
>  > > And anyway, if you are deleting the backing bean in an action-listener
>  > > attached to your button (ie during the invoke-application phase) then
>  > > how is the state of your radio-button being passed through to the
>  > > rendered attribute of the textbox?
>  > >
>  > > Regards,
>  > > Simon
>  > >
>  > >
>  > >>
>  > >> ______________________________________________________________________
>  > >> View this message in context: JSF Lifecycle Question
>  > >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>  > >
>  > >
>  > >
>  >
>
>


-- 
inexso - information exchange solutions GmbH
Bismarckstraße 13      | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX:  +49 441 4082 355 | www.inexso.de
Mime
View raw message