incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Hannum" <dhan...@quovadx.com>
Subject RE: Components reinjected losing disabled state
Date Fri, 23 Mar 2007 16:44:12 GMT
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 <dhannum@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}"/>

Mime
View raw message