Data binding and screen communication

Question

It seems to me that the "backing bean" concept for a view is becoming the common way to implement JSF pages. I just wanted to get some feedback on something I was thinking about concerning the data that the components bind to and communication between screens. I think there are two options:
1) Create a "ViewDataBean" more or less a "sister-bean" to the backing bean, and is stored in session scope. All of the components in the backing bean are bound to the data in the ViewDataBean. That ViewDataBean would also be used to communicate from one screen to the other (binding related pages to the ViewDataBean attributes).
2) Eliminate the "ViewDataBean" and put the actual data in the backing bean itself, binding the components in the backing bean to the data. Communication between screens would then be done by binding components in one backing bean to the data in a different backing bean. This means that all backing beans would be in session scope and I would need to figure out a way to clean them up. Other than that I think this would be a good solution.
I asked this same question during the "Q&A" portion of the "Meet the JSF Expert group", and didn't get a lot of feedback. What do you guys think of this?
Dave

Answer 1

I beleive Adam Winer just said there are some problems in using session beans.
That why many experts will say: "keep session storage to a reasonable minimum."
Inside "blueprints solutions" you can find rules:
Request scope
Information in this scope is created some time after the request is received and is disposed of some time before the response is complete. It is a good practice to have the backing beans for pages be in the request scope where possible, and maintain separate beans that store only the information that will not need to be continually passed between the client and server.
The following types of information are good candidates for storing in the request scope:
Value bindings (e.g. <h:inputText value="#{MyBean.lastName}" /> should always be stored in request scope since they are automatically restored on every request.
Component bindings (e.g. <h:inputText binding="#{MyBean.lastNameComponent}" />) should always be stored in request scope since their value is no longer valid after a request has been processed anyway. The component tree is reconstituted during each incoming request, changing the physical instances these component bindings will point to.
References to database resources such as connections, statements, and result sets should be properly closed and discarded before a request is complete (see the section on resource management below for details).<>
<>Caches of database query results - see section on caching database query results for details.
<>Temporary results of calculations used for rendering the current view.
Session scope
Information in this scope is created some time after the current user's first request is received and is disposed of after a configurable period of inactivity (i.e. when a request has not been received in a certain period of time), or when a session is explicitly invalidated by the application. It is also disposed of when the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.
The following types of information are good candidates for storing in the session scope:
Navigational context, for example the album the user is currently editing in a music catalog application. This type of information could potentially be carefully passed back and forth via hidden input fields, but this is error prone and can be difficult to manage together with form validation and when forms are shared between different parts of an application.
Information that is specific to this session, but temporary, such as short-lived shopping carts. The information can be made persistent by also updating a database table. The recommended way to do this is via entity EJBs, but this can be done by manually coding database-aware JavaBeans as well.
Security sensitive information that should not be continuously sent back and forth between the client and server.
Caches of database query results - see section on caching database query results for details.
Application scope
Information in this scope is created some time after the application starts and is discarded some time before the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.
The following types of information are good candidates for storing in the application scope:
Information that transcends particular users or sessions, such as application settings.
Caches of database query results - see section on caching database query results for detai
I'm sure we just have to make real JSF application, not some kind of jsp or html pages.
Rules for creating real JSF application:
1) using only native JSF navigation
2) using only JSF tags
3) easy way to exchange information between beans
(probably suggestion Adam Winer about input and output parameters for action is good idea in this direction)
4) using only good jsf components
In good JSF application using session scope can't be problem at all.