The reason it affects whether the component exists (in application, although not in memory) is that each piece of phase-processing code starts with the line:
if (!rendered) return; So no phases are executed on non-rendered components. It's as if they don't exist. On 4/27/06, Neuman, Ben J., A&M IRM <[EMAIL PROTECTED]> wrote: > 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. >
