wood burning stoves*
The moose likes JSF and the fly likes Holding off on instantiating a managed bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Holding off on instantiating a managed bean" Watch "Holding off on instantiating a managed bean" New topic
Author

Holding off on instantiating a managed bean

Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

Hey all,

So I'm trying to use panel switching to allow a user to "navigate" through a site. I have code like this:



The problem is that some of the controls on the panelVisualize.xhtml are based on data that is queried from a DB. The managed bean is attempting to populate that data because the component tree is being built even though that page isn't yet visible to the user. Wouldn't be a problem... except that this is even before the user logs in and since the query depends on the username...

So in short, I want to keep that bean from being instantiated until the panel actually becomes visible. I thought of using <c:if test=""> but I understand using JSTL mixed with JSF is bad mojo. I'm sure I'm missing something fundamental here, so any help is appreciated.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15960
    
  19

Beans are instantiated on-demand, which typically means at the first time a render-response is invoked for a view referencing that bean if the bean did not previously exist. As long as that view is dispatched from some other JSF view, the action method of the previous view's backing bean can invoke the proper initialization of the new view's backing bean. In cases of a direct-url reference without a previous JSF view displayed, one has to fall back to alternatives, such as a postconstruct method.

The instantiation of the bean itself cannot be deferred, but you can demote the details to a property of the bean and delay their initialization.


Customer surveys are for companies who didn't pay proper attention to begin with.
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

Hey Tim,

Thanks for the reply. I think the part that's got me confused is related to the rendered attribute. From what I've read, even if rendered="false" the component tree is still being built server side, just not displayed on the client browser. I thought that by not rendering the included page, the associated backing bean wouldn't be instantiated. It seems I was mistaken there, or is there something else I'm missing? Is the component tree for non-rendered included pages also being built on the server?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15960
    
  19

In current JSF implementations, people seem to have been reporting that even if you put "rendered=false" on an included component, that component is still retrieved and scanned. There may be a non-obvious reason for that, for example, so that some future AJAX rendering will have been supplied necessary touch-points.

I have no definite answer to that, but what you are seeing appears to be typical.
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

Heh glad it's not just me...

I did find that using the c:if tag helped, but I want to avoid that if it's not best practice. My understanding is that it is a shaky solution at best.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Holding off on instantiating a managed bean
 
Similar Threads
"#{...} is not allowed in template text" error
Remove managed bean from session
Config & Conditionals In Facelets
Problem with <h:selectManyListbox within <p:dataGrid
JSF rendered