JSF state is restored or used in "Restore View" of JSF life cycle. These state can be stored in 2 places:client and server. There are some links about the difference of them:
http://www.jroller.com/page/mert?entry=state_saving_method_client_side
http://www.jroller.com/page/cagataycivici?entry=jsf_state_saving_best_of
http://www.jroller.com/page/cenkcivici?entry=changing_default_state_management_method
These states are used to store data about the JSF component tree(the elements in f:view), including components and component id. They can be seen between 2 request. That is the difference from backend bean. At first thought most of components have no state, or just have a value which presents its state. A text field has state? But YES. Disable/Enable is a common state. In the component implement java code, saveState and restoreState methods deal all these work: choose some attributes and save them to an object which can be found as a hidden field named javax.faces.ViewState in client's browser source code. It was Base64 encoding. And of course, the view state has been configurated to be stored in the client. In Sun's webui implement, many attributes are stored in view state, such as javascript event method and style.
Some component such as Table can be very complex and has its own states such as the current page number and ordered column. If these states doesn't be stored in component tree, we have to save them in hidden input field.
Myfaces even has a component t:saveState
This technology is powerful when user's action is within one page. When page is refreshed, all he has done are saved. If he just jumps between page, navigate from one page to another page, then the state of a page is discarded, and more it is useless. In one page scenario, AJAX is also a good choice. They all improve user's experience.
Somebody provides stateless approach.
There is a cool tool called FacesTrace to monitor JSF application. It displays not only session data, but also the whole JSF life cycle dynamically.
没有评论:
发表评论