I bet if you used x:saveState for your request bean, that your example would work even though it is a request bean.
Ray --- Dani Kenan <[EMAIL PROTECTED]> wrote: > > 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. > > > === message truncated === __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
