You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Dani Kenan <da...@netvision.net.il> on 2005/02/03 12:12:15 UTC
Serious inherent problem with the JSF framework life cycle and value
binding handling?
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?
Re: Serious inherent problem with the JSF framework life cycle and value binding handling?
Posted by Heath Borders <he...@gmail.com>.
Are you not storing your old value on the session? If not, you might
look at the x:saveState component.
On Mon, 07 Feb 2005 16:48:24 +0200, Dani Kenan <da...@netvision.net.il> wrote:
> You are completely right.
>
> However, for the sake of argument, you should know that the problem is
> manifested in ALL input component due to the responsible code residing in
> UIComponent.validate() which all subcomponent are required to call using
> super.validate() according to the javadoc.
>
> So this solution cannot be considered even as a temporary workaround, as I
> might end up inheriting every component I use.
>
>
> > -----Original Message-----
> > From: Heath Borders [mailto:heath.borders@gmail.com]
> > Sent: Monday, February 07, 2005 4:04 PM
> > To: MyFaces Discussion
> > Subject: Re: Serious inherent problem with the JSF framework life cycle
> > and value binding handling?
> >
> > Just for the sake of argument, you could extend the renderer for
> > whichever component is giving you the trouble, and change its
> > encode/decode behavior so that it saves the value in its attributes
> > map.
> >
> >
> > On Mon, 07 Feb 2005 11:25:18 +0200, Dani Kenan <da...@netvision.net.il>
> > wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Craig McClanahan [mailto:craigmcc@gmail.com]
> > > > Sent: Monday, February 07, 2005 3:01 AM
> > > > To: MyFaces Discussion
> > > > Cc: Sean Schofield
> > > > Subject: Re: Serious inherent problem with the JSF framework life
> > cycle
> > > > and value binding handling?
> > > >
> > > > On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan
> > <da...@netvision.net.il>
> > > > wrote:
> > > >
> > > > >
> > > > > 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.
> > > >
> > > > JSF promises to keep the expressions for all value binding expressions
> > > > that you have set, plus values that you have set directly (not using
> > > > value bindings). If you are expecting the framework to keep the
> > > > values that your VB expressions point at, you are expecting something
> > > > beyond what is promised.
> > >
> > > [Dani Kenan] My only expectation is that the value change listener fires
> > > only when the value changes. Is that too much to ask?
> > >
> > > How this is implemented is not the issue. I did not request the
> > framework to
> > > keep the value that VB expressions point at. In any case even if this is
> > > required in order to fix the way change events are determined, it can be
> > > kept and regarded as an implementation detail and not exposed as a
> > general
> > > feature of the framework.
> > >
> > > The spec reads:
> > >
> > > "2.5.1.3 Executing Validation
> > > ... The converted value is pushed into the component's setValue()
> > method,
> > > and a ValueChangeEvent is fired if the value has changed."
> > >
> > > There is nothing in the spec which prevents a fix. It's a matter of
> > > interpreting what "value has changed" means. I suggest the intuitive
> > > interpretation: changed between the last and current requests.
> > >
> > > >
> > > > If you want to use value change events and request scope backing
> > > > beans, you should bind the *component* into the backing bean instead
> > > > of the *value*. This would cause the following adjustment to your
> > > > initial example:
> > > >
> > > > <h:selectOneMenu id="typeName"
> > > > binding="#{typeListPage.typeName}"
> > > > valueChangeListener="#{typeListPage.onChangeTypeName}">
> > > > <f:selectItems value="#{typeNameSelectItems}" />
> > > > <h:selectOneMenu>
> > > >
> > > > with the following property in your bean that "typeListPage" points
> > at:
> > > >
> > > > private HtmlSelectOneMenu typeName = null;
> > > >
> > > > public HtmlSelectOneMenu getTypeName()
> > > > { return this.typeName; }
> > > >
> > > > public void setTypeName(HtmlSelectOneMenu typeName)
> > > > { this.typeName = typeName; }
> > > >
> > > > In this scenario, JSF saves the value of the component across requests
> > > > (and restores the component reference by calling setTypeName() during
> > > > Restore View phase, so that value change events only fire if the value
> > > > actually changes, as you expect.
> > > >
> > > > If you use value binding expressions, it is your application's
> > > > responsibility to maintain the appropriate state.
> > > >
> > > > Craig McClanahan
> > >
> > > [Dani Kenan] Doesn't this means that for request scoped beans with event
> > > handler the model we must follow is that of ASP.NET?
> > >
> > > Jsf allows you to bind to model elements (value binding) and to ui
> > > components (component binding) where as ASP.NET allows only its version
> > of
> > > component binding, pumping the values between the components and a model
> > is
> > > the developer's job. This results in many ASP.NET applications not
> > having a
> > > backing model at all (and I am talking about complex applications that
> > > should have used one).
> > >
> > > I liked jsf idea of binding to the model better. It would be regretful
> > if it
> > > becomes less usable due to this limitation.
> > >
> > > You suggest resorting to control binding whenever a change listener is
> > > needed. However, this results in some of the ui tree components being
> > > updated automatically and others manually. This inconsistency leads to
> > less
> > > clean design and much less readable code.
> > >
> > > Developers with consistency in mind might feel better off using
> > component
> > > binding all along (ignoring the possibility of value binding) - thus
> > follow
> > > ASP.NET paradigm and end up with the same pitfalls.
> > >
> > > Another reply to my post by Sean Schofield suggested I dump the change
> > > listeners and use the life cycle events in a framework like Struts Shale
> > > (which I suspect you are quite familiar with...) to determine changes
> > and
> > > populate model elements on my own.
> > >
> > > Sean's solution is viable and preserves consistency. And I liked what
> > Struts
> > > Shale has to offer without regard to the value change issue (isPostBack
> > flag
> > > and prerender event to start with).
> > >
> > > Never the less, I still cannot see why I must either move my beans to
> > the
> > > session, or bind to controls and not the model, or neglect event driven
> > > programming all along in order to fix this issue of "value change events
> > > fire without any reason".
> > >
> > > Dani Kenan
> > >
> > >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
RE: Serious inherent problem with the JSF framework life cycle and
value binding handling?
Posted by Dani Kenan <da...@netvision.net.il>.
You are completely right.
However, for the sake of argument, you should know that the problem is
manifested in ALL input component due to the responsible code residing in
UIComponent.validate() which all subcomponent are required to call using
super.validate() according to the javadoc.
So this solution cannot be considered even as a temporary workaround, as I
might end up inheriting every component I use.
> -----Original Message-----
> From: Heath Borders [mailto:heath.borders@gmail.com]
> Sent: Monday, February 07, 2005 4:04 PM
> To: MyFaces Discussion
> Subject: Re: Serious inherent problem with the JSF framework life cycle
> and value binding handling?
>
> Just for the sake of argument, you could extend the renderer for
> whichever component is giving you the trouble, and change its
> encode/decode behavior so that it saves the value in its attributes
> map.
>
>
> On Mon, 07 Feb 2005 11:25:18 +0200, Dani Kenan <da...@netvision.net.il>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Craig McClanahan [mailto:craigmcc@gmail.com]
> > > Sent: Monday, February 07, 2005 3:01 AM
> > > To: MyFaces Discussion
> > > Cc: Sean Schofield
> > > Subject: Re: Serious inherent problem with the JSF framework life
> cycle
> > > and value binding handling?
> > >
> > > On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan
> <da...@netvision.net.il>
> > > wrote:
> > >
> > > >
> > > > 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.
> > >
> > > JSF promises to keep the expressions for all value binding expressions
> > > that you have set, plus values that you have set directly (not using
> > > value bindings). If you are expecting the framework to keep the
> > > values that your VB expressions point at, you are expecting something
> > > beyond what is promised.
> >
> > [Dani Kenan] My only expectation is that the value change listener fires
> > only when the value changes. Is that too much to ask?
> >
> > How this is implemented is not the issue. I did not request the
> framework to
> > keep the value that VB expressions point at. In any case even if this is
> > required in order to fix the way change events are determined, it can be
> > kept and regarded as an implementation detail and not exposed as a
> general
> > feature of the framework.
> >
> > The spec reads:
> >
> > "2.5.1.3 Executing Validation
> > ... The converted value is pushed into the component's setValue()
> method,
> > and a ValueChangeEvent is fired if the value has changed."
> >
> > There is nothing in the spec which prevents a fix. It's a matter of
> > interpreting what "value has changed" means. I suggest the intuitive
> > interpretation: changed between the last and current requests.
> >
> > >
> > > If you want to use value change events and request scope backing
> > > beans, you should bind the *component* into the backing bean instead
> > > of the *value*. This would cause the following adjustment to your
> > > initial example:
> > >
> > > <h:selectOneMenu id="typeName"
> > > binding="#{typeListPage.typeName}"
> > > valueChangeListener="#{typeListPage.onChangeTypeName}">
> > > <f:selectItems value="#{typeNameSelectItems}" />
> > > <h:selectOneMenu>
> > >
> > > with the following property in your bean that "typeListPage" points
> at:
> > >
> > > private HtmlSelectOneMenu typeName = null;
> > >
> > > public HtmlSelectOneMenu getTypeName()
> > > { return this.typeName; }
> > >
> > > public void setTypeName(HtmlSelectOneMenu typeName)
> > > { this.typeName = typeName; }
> > >
> > > In this scenario, JSF saves the value of the component across requests
> > > (and restores the component reference by calling setTypeName() during
> > > Restore View phase, so that value change events only fire if the value
> > > actually changes, as you expect.
> > >
> > > If you use value binding expressions, it is your application's
> > > responsibility to maintain the appropriate state.
> > >
> > > Craig McClanahan
> >
> > [Dani Kenan] Doesn't this means that for request scoped beans with event
> > handler the model we must follow is that of ASP.NET?
> >
> > Jsf allows you to bind to model elements (value binding) and to ui
> > components (component binding) where as ASP.NET allows only its version
> of
> > component binding, pumping the values between the components and a model
> is
> > the developer's job. This results in many ASP.NET applications not
> having a
> > backing model at all (and I am talking about complex applications that
> > should have used one).
> >
> > I liked jsf idea of binding to the model better. It would be regretful
> if it
> > becomes less usable due to this limitation.
> >
> > You suggest resorting to control binding whenever a change listener is
> > needed. However, this results in some of the ui tree components being
> > updated automatically and others manually. This inconsistency leads to
> less
> > clean design and much less readable code.
> >
> > Developers with consistency in mind might feel better off using
> component
> > binding all along (ignoring the possibility of value binding) - thus
> follow
> > ASP.NET paradigm and end up with the same pitfalls.
> >
> > Another reply to my post by Sean Schofield suggested I dump the change
> > listeners and use the life cycle events in a framework like Struts Shale
> > (which I suspect you are quite familiar with...) to determine changes
> and
> > populate model elements on my own.
> >
> > Sean's solution is viable and preserves consistency. And I liked what
> Struts
> > Shale has to offer without regard to the value change issue (isPostBack
> flag
> > and prerender event to start with).
> >
> > Never the less, I still cannot see why I must either move my beans to
> the
> > session, or bind to controls and not the model, or neglect event driven
> > programming all along in order to fix this issue of "value change events
> > fire without any reason".
> >
> > Dani Kenan
> >
> >
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
Re: Serious inherent problem with the JSF framework life cycle and value binding handling?
Posted by Heath Borders <he...@gmail.com>.
Just for the sake of argument, you could extend the renderer for
whichever component is giving you the trouble, and change its
encode/decode behavior so that it saves the value in its attributes
map.
On Mon, 07 Feb 2005 11:25:18 +0200, Dani Kenan <da...@netvision.net.il> wrote:
>
>
> > -----Original Message-----
> > From: Craig McClanahan [mailto:craigmcc@gmail.com]
> > Sent: Monday, February 07, 2005 3:01 AM
> > To: MyFaces Discussion
> > Cc: Sean Schofield
> > Subject: Re: Serious inherent problem with the JSF framework life cycle
> > and value binding handling?
> >
> > On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan <da...@netvision.net.il>
> > wrote:
> >
> > >
> > > 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.
> >
> > JSF promises to keep the expressions for all value binding expressions
> > that you have set, plus values that you have set directly (not using
> > value bindings). If you are expecting the framework to keep the
> > values that your VB expressions point at, you are expecting something
> > beyond what is promised.
>
> [Dani Kenan] My only expectation is that the value change listener fires
> only when the value changes. Is that too much to ask?
>
> How this is implemented is not the issue. I did not request the framework to
> keep the value that VB expressions point at. In any case even if this is
> required in order to fix the way change events are determined, it can be
> kept and regarded as an implementation detail and not exposed as a general
> feature of the framework.
>
> The spec reads:
>
> "2.5.1.3 Executing Validation
> ... The converted value is pushed into the component's setValue() method,
> and a ValueChangeEvent is fired if the value has changed."
>
> There is nothing in the spec which prevents a fix. It's a matter of
> interpreting what "value has changed" means. I suggest the intuitive
> interpretation: changed between the last and current requests.
>
> >
> > If you want to use value change events and request scope backing
> > beans, you should bind the *component* into the backing bean instead
> > of the *value*. This would cause the following adjustment to your
> > initial example:
> >
> > <h:selectOneMenu id="typeName"
> > binding="#{typeListPage.typeName}"
> > valueChangeListener="#{typeListPage.onChangeTypeName}">
> > <f:selectItems value="#{typeNameSelectItems}" />
> > <h:selectOneMenu>
> >
> > with the following property in your bean that "typeListPage" points at:
> >
> > private HtmlSelectOneMenu typeName = null;
> >
> > public HtmlSelectOneMenu getTypeName()
> > { return this.typeName; }
> >
> > public void setTypeName(HtmlSelectOneMenu typeName)
> > { this.typeName = typeName; }
> >
> > In this scenario, JSF saves the value of the component across requests
> > (and restores the component reference by calling setTypeName() during
> > Restore View phase, so that value change events only fire if the value
> > actually changes, as you expect.
> >
> > If you use value binding expressions, it is your application's
> > responsibility to maintain the appropriate state.
> >
> > Craig McClanahan
>
> [Dani Kenan] Doesn't this means that for request scoped beans with event
> handler the model we must follow is that of ASP.NET?
>
> Jsf allows you to bind to model elements (value binding) and to ui
> components (component binding) where as ASP.NET allows only its version of
> component binding, pumping the values between the components and a model is
> the developer's job. This results in many ASP.NET applications not having a
> backing model at all (and I am talking about complex applications that
> should have used one).
>
> I liked jsf idea of binding to the model better. It would be regretful if it
> becomes less usable due to this limitation.
>
> You suggest resorting to control binding whenever a change listener is
> needed. However, this results in some of the ui tree components being
> updated automatically and others manually. This inconsistency leads to less
> clean design and much less readable code.
>
> Developers with consistency in mind might feel better off using component
> binding all along (ignoring the possibility of value binding) - thus follow
> ASP.NET paradigm and end up with the same pitfalls.
>
> Another reply to my post by Sean Schofield suggested I dump the change
> listeners and use the life cycle events in a framework like Struts Shale
> (which I suspect you are quite familiar with...) to determine changes and
> populate model elements on my own.
>
> Sean's solution is viable and preserves consistency. And I liked what Struts
> Shale has to offer without regard to the value change issue (isPostBack flag
> and prerender event to start with).
>
> Never the less, I still cannot see why I must either move my beans to the
> session, or bind to controls and not the model, or neglect event driven
> programming all along in order to fix this issue of "value change events
> fire without any reason".
>
> Dani Kenan
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
RE: Serious inherent problem with the JSF framework life cycle and
value binding handling?
Posted by Dani Kenan <da...@netvision.net.il>.
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: Monday, February 07, 2005 3:01 AM
> To: MyFaces Discussion
> Cc: Sean Schofield
> Subject: Re: Serious inherent problem with the JSF framework life cycle
> and value binding handling?
>
> On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan <da...@netvision.net.il>
> wrote:
>
> >
> > 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.
>
> JSF promises to keep the expressions for all value binding expressions
> that you have set, plus values that you have set directly (not using
> value bindings). If you are expecting the framework to keep the
> values that your VB expressions point at, you are expecting something
> beyond what is promised.
[Dani Kenan] My only expectation is that the value change listener fires
only when the value changes. Is that too much to ask?
How this is implemented is not the issue. I did not request the framework to
keep the value that VB expressions point at. In any case even if this is
required in order to fix the way change events are determined, it can be
kept and regarded as an implementation detail and not exposed as a general
feature of the framework.
The spec reads:
"2.5.1.3 Executing Validation
... The converted value is pushed into the component's setValue() method,
and a ValueChangeEvent is fired if the value has changed."
There is nothing in the spec which prevents a fix. It's a matter of
interpreting what "value has changed" means. I suggest the intuitive
interpretation: changed between the last and current requests.
>
> If you want to use value change events and request scope backing
> beans, you should bind the *component* into the backing bean instead
> of the *value*. This would cause the following adjustment to your
> initial example:
>
> <h:selectOneMenu id="typeName"
> binding="#{typeListPage.typeName}"
> valueChangeListener="#{typeListPage.onChangeTypeName}">
> <f:selectItems value="#{typeNameSelectItems}" />
> <h:selectOneMenu>
>
> with the following property in your bean that "typeListPage" points at:
>
> private HtmlSelectOneMenu typeName = null;
>
> public HtmlSelectOneMenu getTypeName()
> { return this.typeName; }
>
> public void setTypeName(HtmlSelectOneMenu typeName)
> { this.typeName = typeName; }
>
> In this scenario, JSF saves the value of the component across requests
> (and restores the component reference by calling setTypeName() during
> Restore View phase, so that value change events only fire if the value
> actually changes, as you expect.
>
> If you use value binding expressions, it is your application's
> responsibility to maintain the appropriate state.
>
> Craig McClanahan
[Dani Kenan] Doesn't this means that for request scoped beans with event
handler the model we must follow is that of ASP.NET?
Jsf allows you to bind to model elements (value binding) and to ui
components (component binding) where as ASP.NET allows only its version of
component binding, pumping the values between the components and a model is
the developer's job. This results in many ASP.NET applications not having a
backing model at all (and I am talking about complex applications that
should have used one).
I liked jsf idea of binding to the model better. It would be regretful if it
becomes less usable due to this limitation.
You suggest resorting to control binding whenever a change listener is
needed. However, this results in some of the ui tree components being
updated automatically and others manually. This inconsistency leads to less
clean design and much less readable code.
Developers with consistency in mind might feel better off using component
binding all along (ignoring the possibility of value binding) - thus follow
ASP.NET paradigm and end up with the same pitfalls.
Another reply to my post by Sean Schofield suggested I dump the change
listeners and use the life cycle events in a framework like Struts Shale
(which I suspect you are quite familiar with...) to determine changes and
populate model elements on my own.
Sean's solution is viable and preserves consistency. And I liked what Struts
Shale has to offer without regard to the value change issue (isPostBack flag
and prerender event to start with).
Never the less, I still cannot see why I must either move my beans to the
session, or bind to controls and not the model, or neglect event driven
programming all along in order to fix this issue of "value change events
fire without any reason".
Dani Kenan
Re: Serious inherent problem with the JSF framework life cycle and value binding handling?
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan <da...@netvision.net.il> wrote:
>
> 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.
JSF promises to keep the expressions for all value binding expressions
that you have set, plus values that you have set directly (not using
value bindings). If you are expecting the framework to keep the
values that your VB expressions point at, you are expecting something
beyond what is promised.
If you want to use value change events and request scope backing
beans, you should bind the *component* into the backing bean instead
of the *value*. This would cause the following adjustment to your
initial example:
<h:selectOneMenu id="typeName"
binding="#{typeListPage.typeName}"
valueChangeListener="#{typeListPage.onChangeTypeName}">
<f:selectItems value="#{typeNameSelectItems}" />
<h:selectOneMenu>
with the following property in your bean that "typeListPage" points at:
private HtmlSelectOneMenu typeName = null;
public HtmlSelectOneMenu getTypeName()
{ return this.typeName; }
public void setTypeName(HtmlSelectOneMenu typeName)
{ this.typeName = typeName; }
In this scenario, JSF saves the value of the component across requests
(and restores the component reference by calling setTypeName() during
Restore View phase, so that value change events only fire if the value
actually changes, as you expect.
If you use value binding expressions, it is your application's
responsibility to maintain the appropriate state.
Craig McClanahan
RE: Serious inherent problem with the JSF framework life cycle and value binding handling?
Posted by Ray Clark <rc...@yahoo.com>.
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 <da...@netvision.net.il> 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:sean.schofield@gmail.com]
> 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
> <da...@netvision.net.il>
> 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
RE: Serious inherent problem with the JSF framework life cycle and
value binding handling?
Posted by Dani Kenan <da...@netvision.net.il>.
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:sean.schofield@gmail.com]
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 <da...@netvision.net.il>
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?
Re: Serious inherent problem with the JSF framework life cycle and value binding handling?
Posted by Sean Schofield <se...@gmail.com>.
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 <da...@netvision.net.il> 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?