Mike, Thanks for your help. At the moment, however, I do not completely understand how the 'rendered' property affects a component's "existence".
>From the spec: public boolean isRendered() Return true if this component (and its children) should be rendered during the Render Response phase of the request processing lifecycle. Given the above, I would think what I wish to do makes sense. By the way, I'm working on my first JSF project so be patient if I'm completely daft. Ben -----Original Message----- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Thursday, April 27, 2006 10:58 AM To: MyFaces Discussion Subject: Re: Help me understand component lilfecycle please. On 4/27/06, Neuman, Ben J., A&M IRM <[EMAIL PROTECTED]> wrote: > Ok. If my phaseId = RENDER_RESPONSE, beforePhase() is too soon to modify the > component and afterPhase() is too late? That would seem like a weakness in > the spec to me. If there wasn't a rendered tag, sure, this probably would be a weakness. However, in this case, I think it's preventing you from doing something wrong. The rendered attribute affects more than whether the component is drawn -- it affects whether the component "exists" in all phases. It doesn't make a lot of sense for a component to exist without being rendered, and even less sense for it to stop existing during validation or model updating when it previously existed. The proper time to identify the existance of a component is when it's first rendered, and it should then continue to "exist" through the invoke application phase. The rendered attribute does exactly this. The real annoyance is that you can't pass a method (or caller) in EL, so it's hard to implement similar behavior: rendered="#{bean.shouldRenderTab(thisTab)}" Depending on what you're doing, you might be able to wrap your tabs in a dataList, then you can bind the dataList to "bean" and query the dataList for the current tab.
