Shoudn't Managed Bean be part of view state?

Question

Hello,
Why does JSF not identify managed bean as part of view state? After all it is beans which provide the data (model) for components in view. Isn't data part of view state?
There are number of problems with 'request' scoped beans - in fact there are enough reasons to question why JSF allowed 'request' scope in first place.
1. Choice of request scope saves storage, but requires the developers to save the bean data in session and restore that data everytime when the bean is reconstructed on subsequent POST backs.
2. Failure to store or restore the bean's previous data results in NullPointerExceptions during APPLY_REQUEST_VALUES phase, when JSF tries to compare old values with new submitted values to broadcast events.
3. This essentially mean beans are required (with old data) right at the APPLY_REQUEST_VALUES phase, same as the view state.
4. Any storing of data in session creates overhead of cleaning it without fail. Failure to clean results in too big session storage affecting performance.
5. Restoring bean state sometimes also means database calls as early as APPLY_REQUEST_VALUES phase - which is not the right phase for such business logic.
JSF spec should at least provide a way for developers to configure the bean to be saved in view state.

Answer 1

Hello,
Why does JSF not identify managed bean as part of
view state? After all it is beans which provide the
data (model) for components in view. Isn't data part
of view state?No. MVC is about seperating M-V-C. Model - View - Controller. View == page, Model == data. Data can be very large in some cases, storing it with a page (per user) is not scalable and is not a good idea in many cases.
There are number of problems with 'request' scoped
beans - in fact there are enough reasons to question
why JSF allowed 'request' scope in first place. Request scope is very useful for certain things. I think a "pageScope" is missing, which is why I added it to JSFTemplating (https://jsftemplating.dev.java.net). Request scope is not appropriate for all cases.
1. Choice of request scope saves storage, but
requires the developers to save the bean data in
session and restore that data everytime when the bean
is reconstructed on subsequent POST backs.
2. Failure to store or restore the bean's previous
data results in NullPointerExceptions during
APPLY_REQUEST_VALUES phase, when JSF tries to compare
old values with new submitted values to broadcast
events.
3. This essentially mean beans are required (with old
data) right at the APPLY_REQUEST_VALUES phase, same
as the view state.Both managed beans and the request scope map itself can make this happen transparently.
4. Any storing of data in session creates overhead of
cleaning it without fail. Failure to clean results in
too big session storage affecting performance.I agree.
5. Restoring bean state sometimes also means database
calls as early as APPLY_REQUEST_VALUES phase - which
is not the right phase for such business logic.Depends on how you write your beans / application.
JSF spec should at least provide a way for developers
to configure the bean to be saved in view state.You don't have to use beans let alone use "managed" beans. If you feel your application would be better off storing data w/ the view state... get the UIViewRoot, call setAttribute("key", yourData).
Good luck!
Ken Paulsen
https://jsftemplating.dev.java.net