Scott,
Yeah, this is a spot that can get a little awkward.
It feels most natural (maybe because of my WO experience) to allow the
page to init instance variables and pass them to components on the
page. Where you hit a snag is when the component needs to init
additional things based on a parameter(s) passed into the component.
The component's pageBeginRender() method is being called before page
is initialized and the parameter is passed to the component. Bummer.
:-|
What I do is bag initializing components in pageBeginRender() and do
it lazily. It's kind of a lamo pattern, but it hasn't gotten me in
trouble.
public abstract Object getMyObject();
public abstract void setMyObject(Object value);
public abstract Object getMyInflatedObject() {
if (getMyObject() == null) {
Object foo; // init my object, pg should be initialized, params passed
setMyObject(foo);
}
return getMyObject();
}
In my .html/.jwc files I always reference the inflated method.
Hope that helps.
Cheers,
Eric
On 1/4/06, Jeff Lubetkin <[EMAIL PROTECTED]> wrote:
> We ran into the same problem. As far as I can tell, the only way to
> guarantee this ordering is to use override prepareForRender on the component,
> and not use PageBeginRenderListener.
>
> jeff
>
> ________________________________
>
> From: Scott Russell [mailto:[EMAIL PROTECTED]
> Sent: Tue 1/3/2006 10:05 PM
> To: [email protected]
> Subject: Guaranteed order of PageBeginRender
>
>
>
> I am finding problems with the use of PageBeginRender.
>
> If you use the listener on nested components as well as the nesting page, one
> would expect the nesting page's PageBeginRender to be called first, then that
> of the nested components, from outer to inner. However, it appears that the
> inner components are called first before the page.
>
> This causes problems because I want to initialise some page properties within
> the page's PageBeginRender, which the nested components rely on. At the
> moment I am getting NullPointerExceptions because of this event ordering.
>
> Shouldn't the PageBeginRender listeners be called outer to inner? Or is there
> another way to avoid this sort of problem?
>
> regards,
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
