• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ViewScoped bean constructor being called twice

 
Greenhorn
Posts: 2
Netbeans IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to implement a program that populates a dataTable on one page, and displays the details of the the selected row on another page for either viewing or editing. The backing bean for my detail page (call it DetailBackingBean) is ViewScoped. This bean is pretty straight forward, except for one variable which I will talk about the bean is all getters and setters with some basic functionality for enabling/disabling inputText boxes. This bean also sets the value of a variable in the constructor. This variable is defined in a parent bean I import into my DetailBackingBean (call the parent bean BaseBean).

Okay, BaseBean is very simple. It defines this one variable (a protected String) and provides the getter and setter for it. This variable is called toolbarDescription. BaseBean is @RequestScoped.

When I put a breakpoint in my DetailBackingBean on the variable definition for toolbarDescription (which is in my constructor) I note that the DetailBackingBean constructor is called when I navigate from my dataTable page to my detail page. So far so good. Whether or not the detail page is set to "view" (inputText boxes are disabled so information is displayed only) or to "edit" (inputText boxes are enabled so data can be edited) - whenever I press the commandButton to "submit changes" or to "cancel" the DetailBackingBean constructor is called a second time.

Is this happening because the BaseBean is @RequestScoped? Is there a way to keep the BaseBean as a "@ManagedBean" in "@RequestScoped" and not have the UserDetailBean constructor called twice? I was able to make this work by making BaseBean abstract and removing the "@ManagedBean" and "@RequestScoped" annotations, but that is not how my boss wants this to work. Can anyone provide insight as to why the constructor is called twice? Any suggestions for correcting this behavior without going the abstract route?

Do faces-config navigation rules (with or without <redirect /> tags) have any effect on this?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
RequestScoped beans are created (constructed) and destroyed on each HTTP request.

ViewScoped beans (new in JSF 2) are created on first reference, but destroyed when a new view is navigated to.

SessionScoped beans are created on first reference, and only destroyed by explicit request, such a a session.invalidate() or a session.removeAttribute(beanName) method call.

Since you can't inject a short lifespan object into one with a longer lifespan, the technique that works best in most cases is that where you have a table-select/edit-or-view-detail arrangement is to give the table view a Session scope object. That way you don't lose the table datamodel when you go to the edit or display detail views. You can use ViewScope for the detail views. I've also used RequestScope for detail views.

For best results on a detail edit, I recommend cloning the model object or otherwise maintaining an intermediate data model. That way, if someone wants a "cancel" or "undo" function, the original model object remains undamaged.
reply
    Bookmark Topic Watch Topic
  • New Topic