Hi Sean, Thanks for your response.
I do not agree that session scope should be used for backing beans, just for very few. Once the bean is not needed from the application point of view it cannot be kept in the session just because the framework used is technically incompetent. Unfortunately, most of the JSF examples I see pollute the session with dangling beans instead of keeping the beans in the request. With the simple scenario I provided it is quite clear that a change event is fired although no change has occurred. How is this not problematic? It seems quite clear that change event handlers cannot be used together with value properties bound to request scope beans, since they will always be invoked. This should be recognized as a limitation of the current implementations of JSF. This limitation can be eliminated easily if the literal value of the control is saved, then restored and then used to determine if a change occurred. Currently, for bound values, the actual value is not saved in the state (thus not restored) and not used for comparison against the posted value. The comparison is done between the new value in the post data and the not yet initialized bean property. You could say this is a matter of view: what are the values we need to compare to determine a change. Due to the consequences I think it is obvious what the answer is. Struts Shale (or a similar framework) is exactly what we need. JSF is lacking some basic services and feature needed by almost any non-trivial (and even trivial) application. Unless such a framework becomes a standard each and every project using JSF would need to build a supporting framework of its own. Shale can help a lot and maybe allow us to bypass the above limitation by avoiding the use of change handlers altogether. However I cannot see how it can solve the above limitation if you do want to use the Change Event pattern (which, when working, can be very useful and intuitive). Regards, Dani -----Original Message----- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Sunday, February 06, 2005 9:41 PM To: MyFaces Discussion Subject: Re: Serious inherent problem with the JSF framework life cycle and value binding handling? 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?
