All,
I know I am joining this discussion late, however, I just went through the
painful process of writing my own component library because I could not get the
components during the render response phase. My idea was that I should be able
to get the component id and based on that do some additional security checking.
If it fails then set rendered = false. It would be clean. However. . . no go.
>>However, it's also possible to configure it by using a binding
>>attribute -- you bind the attribute to a backing bean, and then,
>>depending on whether you use set or get, you can either modify the
>>preconstructed component, or create your own version of the component
>>yourself.
Did that and it is more work than I had hoped.
Also cluttering my code with
<sometag value="..." isRendered="{bean.method}"/>
and then
class SomeBean
{
public boolean isMethod()
{
//do some boilerplate stuff
}
}
seems like a lot of replicated redundant code.
A thought I had was that it would be nice if we could set up a
JSFRenderCallbackHandler. This object would be configured in the
faces-config.xml file and would be called during the isRendered phase of the
component lifecycle passing in the component as its arg. . . or the id(?).
This would remove the boilerplate and not force developers to write a component
library. Also a JSFDisabledCallbackHandler would be nice.
My 2 cents,
Rhys
-----Original Message-----
From: Neuman, Ben J., A&M IRM [mailto:[EMAIL PROTECTED]
Sent: April 27, 2006 2:15 PM
To: 'MyFaces Discussion'
Subject: RE: Help me understand component lilfecycle please.
Not sure I understand. Are you referring to the binding of a component's
attribute to a backing bean? Or the binding of the component itself to a
backing bean?
-----Original Message-----
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 27, 2006 12:24 PM
To: MyFaces Discussion
Subject: Re: Help me understand component lilfecycle please.
On 4/27/06, Neuman, Ben J., A&M IRM <[EMAIL PROTECTED]> wrote:
> Got it. It makes sense to me to "disregard" unrendered components during
> phase-processing code. I guess I have issues with the inability to modify
> components before the initial rendering. Still feel this is a spec
weakness.
Well, you "configure" a component by specifying attributes.
However, it's also possible to configure it by using a binding
attribute -- you bind the attribute to a backing bean, and then,
depending on whether you use set or get, you can either modify the
preconstructed component, or create your own version of the component
yourself.
Sorry I didn't point this out earlier as this might be what you wanted.
