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?
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.
Customer surveys are for companies who didn't pay proper attention to begin with.