I think the key here is that the rendered condition is checked *after* the button has been clicked, and, if you haven't saved the state of the bean that contains the boolean value, it will get re-initialized with null values (and false values) when it is referenced and the decision is made to create the action button component.
This also happens with non-action components, but it doesn't matter with those, since they don't do anything on the next request anyway. - Brendan -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 3:50 PM To: MyFaces Discussion Subject: Re: understanding the impact of 'rendered' 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
