myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dani Kenan <>
Subject Serious inherent problem with the JSF framework life cycle and value binding handling?
Date Thu, 03 Feb 2005 11:12:15 GMT
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,

         <f:selectItems value="#{typeNameSelectItems}" />

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?

View raw message