>From: "Daniel Hannum" <[EMAIL PROTECTED]>
>
> 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?
>
You could create a "constants" managed bean that you placed in application
scope to hold your magic numbers.
<yourComponent disabled="#{radioButtonValue eq constants.radioButtonValue}"/>
>
> -----Original Message-----
> From: noah [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 23, 2007 12:29 PM
> To: [email protected]
> Subject: Re: Components reinjected losing disabled state
>
> On 3/23/07, Daniel Hannum 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.
>
>
>
>
