File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Holding off on instantiating a managed bean

 
Guy deLyonesse
Ranch Hand
Posts: 200
Eclipse IDE Java Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 17616
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Guy deLyonesse
Ranch Hand
Posts: 200
Eclipse IDE Java Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 17616
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 200
Eclipse IDE Java Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic