It makes the most sense for UIInput components since you don't want to applyValues/validate/updateModel on a component that wasn't rendered.
It's not as obvious why it is done for actions, and I'm not going to try to justify it :) You only have to use saveState in this situation if your button is conditionally rendered based on a request-scoped backing bean. On 9/9/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Mike Kienenberger wrote the following on 9/9/2005 4:38 PM: > > Doing a saveState on employeeAction.editMode or employeeAction should > > preserve it. > > Thanks Mike! Yup that did it. > > However, I have to admit, this necessity seems very silly me. > > I understand from the docs that it says: > > rendered: Flag indicating whether or not this component should be > rendered (during Render Response Phase), *or processed on any subsequent > form submit. > > > Is there not the concept of just being able to render a button based on > some logic where the rendered condition doesn't need to also be true > when the form submits? With JSTL I could wrap the display of my buttons > in a c:choose/when construct but I'm not aware of that construct with > JSF and everyone seems to mention that 'rendered' is for this puprose - > but the fact that I have to preserve the state of the rendered condition > seems a bit overkill for what I need. > > I guess it's not a big deal to put "x:saveState" on practically all my > pages, but I'm just not sure what kind of extra overhead that costs > (overhead that I think is unnecessary in this case). > > - > Rick >
