Dani,
I used to think this behavior would be problematic but I have since
changed my mind on that.
First, as you mention, if the managed bean has session scope, then
there is no issue. That probably covers some scenarios where the data
is not subject to a lot of change (or data is user specific.)
For request scope managed beans, they are going to be recreated with
each request. That's why you specify them to be request scope after
all. I think the fact that the bean properties are reset on the post
is not an issue and in fact that is expected behavior.
Forget value change events for a second. Ask yourself how you are
planning on populating your request-scope beans to begin with? There
are various mechanisms to do this (I personally am leaning towards
some of the ViewController methods in Craig's Struts Shale effort.)
In any event, this data is ultimately coming from a data source of
some type. So whatever steps you take to populate the bean the first
time, just repeat each time the bean is instiated.
If you do this, you shouldn't run into any of the scenarios you are describing.
sean
On Thu, 03 Feb 2005 13:12:15 +0200, Dani Kenan <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi all,
>
> I think there are some serious inherent problem with the JSF framework life
> cycle and value binding handling. Here is an example how a ValueChangeEvent
> always gets fired, even w/o any changes:
>
> When the value property is bound to a request scoped managed bean field,
> e.g.: <h:selectOneMenu id="typeName" value="#{typeListPage.typeName}"
> valueChangeListener="#{typeListPage.onChangeTypeName}">
> <f:selectItems value="#{typeNameSelectItems}" /><h:selectOneMenu>
>
>
>
> The event is fired in every post to the server, even if no change occurred.
>
> During the apply request phase/validation phase the selectOneMenu component
> compares the newly posted value with the WRONG old value
> thus fires the event.
>
> In order to determine if a value change occured, the value posted in the
> request (which is never null) is compared agains the current value of the
> bean property (due to the bining #{typeListPage.typeName}). This propety
> which is not yet initialized in request scope bean - thus always null), and
> the value change event fires.
>
> Because the value property is bound to the bean field
> #{typeListPage.typeName} it is never saved during the saveState() - value is
> always saved as null and is restored to be null and in any case not applied
> on the managed bean . This leaves the bean to be responsible to maintain the
> inter-request state of the property. But... this is a request scope bean.
>
> Only if we change the bean to be session scoped will the event not fire. If
> the bean saves it own state between requests then this is solved - but many
> other problems arise, and in any case, why do we need the jsf state
> mangement if we eventually need to save everything in the session.
>
> Does anybody else find this behavior problematic?
