Re: UI component behavior problem

[Simon Kitching <sk...@obsidium.com>]

Matthias Kahlau wrote:
> Hi!
> 
> 
> I have a page with a form that contains some input elements like inputText
> etc. When I change the selection in a selectOneMenu, the page is submitted
> (immediate = true), and the valueChangeListener invoked, and then the render
> response phase is directly processed and the page redisplayed with all the
> content that I added in the input components previously. All is fine.
> 
> But when I leave the page to get to a second page (to edit details) via a
> commandLink (immediate = true), and then cancel back to the first page
> (immediate = true), it seems that all input components of the first page are
> resetted to their original state, and the text I inputted is deleted.
> 
> Can anybody explain, why JSF behaves like I described, and how I can prevent
> the input components from beeing resetted?

Values in JSF can be sitting in two places:
  * just in the component
  * pushed into the "model"

When "immediate" + renderResponse is being used, the values sit in the 
component and never get pushed into the model.

And when you navigate to a different view, the old view (including its 
associated components) gets discarded. On return to the page a new set 
are created.

So what you're seeing is exactly what's expected. You're such a heavy 
user of immediate+renderResponse that values never get pushed to 
somewhere that they can be made persistent across views.

So, about "fixing" the behaviour:

I expect you could use "immediate=false" on the commandlink. Assuming 
all these input fields you're worried about have value-bindings, that 
will push the values into your backing beans. On return to the page, the 
components will then pull them back from the backing beans. However 
validation *will* be applied when the link is clicked, and if validation 
fails then navigation to the details page will be prevented.

Or you could make your selectOneMenu non-immediate, and don't use 
renderResponse. Again, that will cause data to be pushed to a backing 
bean from which it can later be retrieved by a new copy of the view.

There was some work done a while ago on saving views away to handle 
back-button usage. Maybe that could help you, but I don't know much 
about it.

Regards,

Simon

AW: UI component behavior problem

[Matthias Kahlau <mk...@web.de>]

Hi Simon!


Many thanks for your enlightening response.

> And when you navigate to a different view, the old view (including its
> associated components) gets discarded. On return to the page a new set
> are created.

That was the point I didn't know, which caused that I didn't understand why
the submitted and not updated values of the first page were discarded after
returning from the second page to the first.

> I expect you could use "immediate=false" on the commandlink. Assuming
> all these input fields you're worried about have value-bindings, that
> will push the values into your backing beans. On return to the page, the
> components will then pull them back from the backing beans. However
> validation *will* be applied when the link is clicked, and if validation
> fails then navigation to the details page will be prevented.


I think that's some kind of problem with JSF. I want the validation to be
applied when the form is submitted to save, of cource, at the end of the
user task. But I do not want the page to be validated only when the user
navigates to an edit details page, which is part of the form of the first
page. I also do not want the page to be validated only when the user changes
a selection in a selectOneMenu. Both will break the user work flow, because
the selectOneMany or the edit details link comes logically before some other
input components, or worse, depend on the selection of the selectOneMenu or
selectOneRadio -> that would cause that the user has to input mandatory info
which is not relevant or required after the selection, which may show a
partly different form.

Of cource, one solution would be to abandon the JSF validation, but that
means more work in the application code, and a lesser beautiful solution.

> There was some work done a while ago on saving views away to handle
> back-button usage. Maybe that could help you, but I don't know much
> about it.

That sounds very interesting to me. Do you know where I can get more info
about it?


Regards,
Matthias

> -----Ursprüngliche Nachricht-----
> Von: users-return-13071-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-13071-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von Simon Kitching
> Gesendet: Donnerstag, 1. Dezember 2005 03:07
> An: MyFaces Discussion
> Betreff: Re: UI component behavior problem
>
>
> Matthias Kahlau wrote:
> > Hi!
> >
> >
> > I have a page with a form that contains some input elements
> like inputText
> > etc. When I change the selection in a selectOneMenu, the page
> is submitted
> > (immediate = true), and the valueChangeListener invoked, and
> then the render
> > response phase is directly processed and the page redisplayed
> with all the
> > content that I added in the input components previously. All is fine.
> >
> > But when I leave the page to get to a second page (to edit
> details) via a
> > commandLink (immediate = true), and then cancel back to the first page
> > (immediate = true), it seems that all input components of the
> first page are
> > resetted to their original state, and the text I inputted is deleted.
> >
> > Can anybody explain, why JSF behaves like I described, and how
> I can prevent
> > the input components from beeing resetted?
>
> Values in JSF can be sitting in two places:
>   * just in the component
>   * pushed into the "model"
>
> When "immediate" + renderResponse is being used, the values sit in the
> component and never get pushed into the model.
>
> And when you navigate to a different view, the old view (including its
> associated components) gets discarded. On return to the page a new set
> are created.
>
> So what you're seeing is exactly what's expected. You're such a heavy
> user of immediate+renderResponse that values never get pushed to
> somewhere that they can be made persistent across views.
>
> So, about "fixing" the behaviour:
>
> I expect you could use "immediate=false" on the commandlink. Assuming
> all these input fields you're worried about have value-bindings, that
> will push the values into your backing beans. On return to the page, the
> components will then pull them back from the backing beans. However
> validation *will* be applied when the link is clicked, and if validation
> fails then navigation to the details page will be prevented.
>
> Or you could make your selectOneMenu non-immediate, and don't use
> renderResponse. Again, that will cause data to be pushed to a backing
> bean from which it can later be retrieved by a new copy of the view.
>
> There was some work done a while ago on saving views away to handle
> back-button usage. Maybe that could help you, but I don't know much
> about it.
>
> Regards,
>
> Simon