myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rhys Parry" <rpa...@Infoterra.com>
Subject RE: Help me understand component lifecycle please.
Date Thu, 27 Apr 2006 18:47:20 GMT
Ben,

If you wouold like to take this off-line I can share my knowledge on the subject.  In the
end I created a bunch of aspects ( compile time aspectJ (although runtime would be preferable))
that should not be a problem to use.

If you would like email me at rparry@infoterra.com


Rhys Parry


-----Original Message-----
From: Neuman, Ben J., A&M IRM [mailto:bjneuman@hq.afis.osd.mil]
Sent: April 27, 2006 2:43 PM
To: 'MyFaces Discussion'
Subject: RE: Help me understand component lifecycle please.


Rhys, I think you hit the nail on the head. You can't get the component
during the initial render response phase. The workarounds seem like an awful
lot of work for my needs. 

-----Original Message-----
From: Rhys Parry [mailto:rparry@Infoterra.com]
Sent: Thursday, April 27, 2006 2:40 PM
To: MyFaces Discussion
Subject: RE: Help me understand component lifecycle please.


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:bjneuman@hq.afis.osd.mil]
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:mkienenb@gmail.com]
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 <bjneuman@hq.afis.osd.mil> 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.

Mime
View raw message