You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Daniel Hannum <dh...@quovadx.com> on 2007/03/23 14:24:36 UTC
Components reinjected losing disabled state
This may be a basic JSF question... I'm not sure.
I have a component on a page that is bound to a backing bean member.
During page logic, I use setDisabled(true) to disable the component
under some conditions. Now, after the form is submitted, JSF seems to
reinject new component objects into my backing bean. So, the next time
the page is displayed, loses the disabled state. I didn't know it would
do this. I guess I thought I would get to keep my component instances
and not have new ones given to me on each request.
As far as a solution goes, I guess I could put logic in the getter
(getMyComponent()) for figuring out if we should be disabled or not.
That way it would always be done, but it seems inefficient to do it
every time.
Does that seem like the best solution? I know putting the logic in the
markup itself would also work, though I think I need to do more than EL
can do (I need to check if a radio button has a particular value).
Thoughts?
Thanks.
Re: Components reinjected losing disabled state
Posted by Mike Kienenberger <mk...@gmail.com>.
Actions don't reset the tree if you return null.
And there's no reason why you couldn't use an actionListener. An
ActionListener is just an Action that returns null.
As for putting magic numbers in the UI, use EL to pull it from your java code.
<yourComponent disabled="#{radioButtonValue == backingBean.yourMagicNumber}"/>
On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> It's not request scoped, so I could do
>
> public MyComponent getMyComponent() {
> myComponent.setDisabled(radioButtonValue == 1);
> return myComponent;
> }
>
> But that's ugly
>
> Best way to keep it from reseting is do it in the markup
>
> <yourComponent disabled="#{radioButtonValue == 1}"/>
>
> But that's putting a magic number in the UI. Not good.
>
> actionListeners were recommended because they don't reset the component
> tree, but I don't like it because I really do need to do business logic,
> it just happens to bring you back to the same page. Actions seem like
> the right thing, but they reset the tree, and there's no good place to
> put the components back the way they're supposed to be.
>
> Still seems to be no good solution. Is there something I'm not seeing?
>
>
> -----Original Message-----
> From: noah [mailto:iamnoah@gmail.com]
> Sent: Friday, March 23, 2007 12:29 PM
> To: adffaces-user@incubator.apache.org
> Subject: Re: Components reinjected losing disabled state
>
> On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> > This may be a basic JSF question... I'm not sure.
> >
> >
> >
> > I have a component on a page that is bound to a backing bean member.
> > During page logic, I use setDisabled(true) to disable the component
> > under some conditions. Now, after the form is submitted, JSF seems to
> > reinject new component objects into my backing bean. So, the next time
> > the page is displayed, loses the disabled state. I didn't know it
> would
> > do this. I guess I thought I would get to keep my component instances
> > and not have new ones given to me on each request.
> >
> >
> >
> > As far as a solution goes, I guess I could put logic in the getter
> > (getMyComponent()) for figuring out if we should be disabled or not.
> > That way it would always be done, but it seems inefficient to do it
> > every time.
> >
>
> If checking disabled is an expensive operation, then cache the result,
> e.g.
>
> public boolean isDisabled() {
> if(this.disabled == null) {
> this.disabled = expensiveCalculation();
> }
> return disabled;
> }
>
> But you'll need some other logic to determine if disabled needs to be
> reevaluated, unless your bean is request scoped.
>
> >
> > Does that seem like the best solution? I know putting the logic in the
> > markup itself would also work, though I think I need to do more than
> EL
> > can do (I need to check if a radio button has a particular value).
> >
>
> Then probably you should be checking if the property the radio button
> is bound to has a particular value, rather than checking the actual
> radio button. e.g.
>
> <tr:selectBooleanRadio value="#{myBean.disable}"/>
>
> <yourComponent disabled="#{myBean.disable}"/>
>
RE: Components reinjected losing disabled state
Posted by Daniel Hannum <dh...@quovadx.com>.
All sorts of options...
Simply using the null outcome is the easiest fix, but I agree that it
should be defining disabledness in the xhtml and using a method as you
describe that would contain that logic, or include the login in the
xhtml if it's simple.
Thanks!
-----Original Message-----
From: noah [mailto:iamnoah@gmail.com]
Sent: Friday, March 23, 2007 3:48 PM
To: adffaces-user@incubator.apache.org
Subject: Re: Components reinjected losing disabled state
On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> It's not request scoped, so I could do
>
> public MyComponent getMyComponent() {
> myComponent.setDisabled(radioButtonValue == 1);
> return myComponent;
> }
>
> But that's ugly
>
> Best way to keep it from reseting is do it in the markup
>
> <yourComponent disabled="#{radioButtonValue == 1}"/>
>
> But that's putting a magic number in the UI. Not good.
>
> actionListeners were recommended because they don't reset the
component
> tree, but I don't like it because I really do need to do business
logic,
> it just happens to bring you back to the same page. Actions seem like
> the right thing, but they reset the tree, and there's no good place to
> put the components back the way they're supposed to be.
>
> Still seems to be no good solution. Is there something I'm not seeing?
What would be wrong with:
<yourComponent disabled="#{yourBean.isXDisabled}"/>
and yourBean having:
public boolean isXDisabled() {
return radioButtonValue == 1;
}
That way the disabledness of the component isn't coupled directly to
the radioButton.
Re: Components reinjected losing disabled state
Posted by noah <ia...@gmail.com>.
On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> It's not request scoped, so I could do
>
> public MyComponent getMyComponent() {
> myComponent.setDisabled(radioButtonValue == 1);
> return myComponent;
> }
>
> But that's ugly
>
> Best way to keep it from reseting is do it in the markup
>
> <yourComponent disabled="#{radioButtonValue == 1}"/>
>
> But that's putting a magic number in the UI. Not good.
>
> actionListeners were recommended because they don't reset the component
> tree, but I don't like it because I really do need to do business logic,
> it just happens to bring you back to the same page. Actions seem like
> the right thing, but they reset the tree, and there's no good place to
> put the components back the way they're supposed to be.
>
> Still seems to be no good solution. Is there something I'm not seeing?
What would be wrong with:
<yourComponent disabled="#{yourBean.isXDisabled}"/>
and yourBean having:
public boolean isXDisabled() {
return radioButtonValue == 1;
}
That way the disabledness of the component isn't coupled directly to
the radioButton.
RE: Components reinjected losing disabled state
Posted by Daniel Hannum <dh...@quovadx.com>.
It's not request scoped, so I could do
public MyComponent getMyComponent() {
myComponent.setDisabled(radioButtonValue == 1);
return myComponent;
}
But that's ugly
Best way to keep it from reseting is do it in the markup
<yourComponent disabled="#{radioButtonValue == 1}"/>
But that's putting a magic number in the UI. Not good.
actionListeners were recommended because they don't reset the component
tree, but I don't like it because I really do need to do business logic,
it just happens to bring you back to the same page. Actions seem like
the right thing, but they reset the tree, and there's no good place to
put the components back the way they're supposed to be.
Still seems to be no good solution. Is there something I'm not seeing?
-----Original Message-----
From: noah [mailto:iamnoah@gmail.com]
Sent: Friday, March 23, 2007 12:29 PM
To: adffaces-user@incubator.apache.org
Subject: Re: Components reinjected losing disabled state
On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> This may be a basic JSF question... I'm not sure.
>
>
>
> I have a component on a page that is bound to a backing bean member.
> During page logic, I use setDisabled(true) to disable the component
> under some conditions. Now, after the form is submitted, JSF seems to
> reinject new component objects into my backing bean. So, the next time
> the page is displayed, loses the disabled state. I didn't know it
would
> do this. I guess I thought I would get to keep my component instances
> and not have new ones given to me on each request.
>
>
>
> As far as a solution goes, I guess I could put logic in the getter
> (getMyComponent()) for figuring out if we should be disabled or not.
> That way it would always be done, but it seems inefficient to do it
> every time.
>
If checking disabled is an expensive operation, then cache the result,
e.g.
public boolean isDisabled() {
if(this.disabled == null) {
this.disabled = expensiveCalculation();
}
return disabled;
}
But you'll need some other logic to determine if disabled needs to be
reevaluated, unless your bean is request scoped.
>
> Does that seem like the best solution? I know putting the logic in the
> markup itself would also work, though I think I need to do more than
EL
> can do (I need to check if a radio button has a particular value).
>
Then probably you should be checking if the property the radio button
is bound to has a particular value, rather than checking the actual
radio button. e.g.
<tr:selectBooleanRadio value="#{myBean.disable}"/>
<yourComponent disabled="#{myBean.disable}"/>
Re: Components reinjected losing disabled state
Posted by noah <ia...@gmail.com>.
On 3/23/07, Daniel Hannum <dh...@quovadx.com> wrote:
> This may be a basic JSF question... I'm not sure.
>
>
>
> I have a component on a page that is bound to a backing bean member.
> During page logic, I use setDisabled(true) to disable the component
> under some conditions. Now, after the form is submitted, JSF seems to
> reinject new component objects into my backing bean. So, the next time
> the page is displayed, loses the disabled state. I didn't know it would
> do this. I guess I thought I would get to keep my component instances
> and not have new ones given to me on each request.
>
>
>
> As far as a solution goes, I guess I could put logic in the getter
> (getMyComponent()) for figuring out if we should be disabled or not.
> That way it would always be done, but it seems inefficient to do it
> every time.
>
If checking disabled is an expensive operation, then cache the result, e.g.
public boolean isDisabled() {
if(this.disabled == null) {
this.disabled = expensiveCalculation();
}
return disabled;
}
But you'll need some other logic to determine if disabled needs to be
reevaluated, unless your bean is request scoped.
>
> Does that seem like the best solution? I know putting the logic in the
> markup itself would also work, though I think I need to do more than EL
> can do (I need to check if a radio button has a particular value).
>
Then probably you should be checking if the property the radio button
is bound to has a particular value, rather than checking the actual
radio button. e.g.
<tr:selectBooleanRadio value="#{myBean.disable}"/>
<yourComponent disabled="#{myBean.disable}"/>