This blog is to highlight why we should register our beans in backing bean scope.
ADF supports following scopes: backingbean, request, view, pageFlow, session and application.
As a good practice we should register our beans in backingbean scope.
1. Why we should not use view, pageFlow, session, application: System needs to serialize any information in these scopes during fail over and also when user times out. Generally we bind UI components with a bean and these components are not serializable so if bean is registered in above scopes it will not get serialized and serialization will fail.
2. Why we should not use requestScope: Serialization is not a problem if bean is registered in request scope because system does not serialize any object that is present in request scope. That make sense also because anything that is in request scope should be lost in next request so what is the point to serialize that information. BUT still we should not register our beans in request scope. That is because if we use a task-flow on a page twice and task-flow has a request-scope bean, both instances of task-flow will start sharing same instance of bean. It can create a lot of confusion.
3. Why should we use backing-bean Scope: Backing bean scope is almost same a request scope in terms of life cyle so system need not to serialize any such bean. Also we get advantage that system create two instances of bean if we use task-flow twice on a page.
4. Is it good enough: Now question is "Can we meet all requirements by storing beans in backing-bean scope?". I would say most of the time YES, you can. Mostly we need to put certain INFORMATION on higher scopes (like pageFlow, session, application) and to store that we don't need to put bean in that scope. We can directly put INFORMATION (or value) in scope. For example we have a 4 page task-flow, which has employee search on first page and user can select an employee on first page. After selecting employee user can navigate to page 2, 3, 4. On page 4 we need to know selected employee record.
To achieve this one developer do following
a. Bind employee table of first page on a page-flow bean
b. Bind table with the bean.
c. On page 4, get page-flow bean and then get table and then try to get selected employee row.
Other developer can follow this approach
a. Bind employee table of first page on backingbean-scoped bean
b. Bind table with that bean
c. While navigating to page-2 get selected row from employee table and store its (employee-id or any other needed information) in page-flow scope. If you need complete employee information you can create employee-pojo (object) and set its attribute and then store employee object in page-flow
d. Access employee information from page-flow scope.
[IF you are using bindings and on selection you have selection listener which makes employee row current, you can directly create binding of same vo on page-4. That could be even better]
We see mostly we need to information on different pages, so its better to store those information on needed scope rather than bean.
5. If you really want to store bean in higher scopes: If you really need bean in higher scopes atleast use ComponentReference.
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/util/ComponentReference.html
Disclaimer: Any views or opinions presented in this blog are solely those of the author and do not necessarily represent those of the company.
ADF supports following scopes: backingbean, request, view, pageFlow, session and application.
As a good practice we should register our beans in backingbean scope.
1. Why we should not use view, pageFlow, session, application: System needs to serialize any information in these scopes during fail over and also when user times out. Generally we bind UI components with a bean and these components are not serializable so if bean is registered in above scopes it will not get serialized and serialization will fail.
2. Why we should not use requestScope: Serialization is not a problem if bean is registered in request scope because system does not serialize any object that is present in request scope. That make sense also because anything that is in request scope should be lost in next request so what is the point to serialize that information. BUT still we should not register our beans in request scope. That is because if we use a task-flow on a page twice and task-flow has a request-scope bean, both instances of task-flow will start sharing same instance of bean. It can create a lot of confusion.
3. Why should we use backing-bean Scope: Backing bean scope is almost same a request scope in terms of life cyle so system need not to serialize any such bean. Also we get advantage that system create two instances of bean if we use task-flow twice on a page.
4. Is it good enough: Now question is "Can we meet all requirements by storing beans in backing-bean scope?". I would say most of the time YES, you can. Mostly we need to put certain INFORMATION on higher scopes (like pageFlow, session, application) and to store that we don't need to put bean in that scope. We can directly put INFORMATION (or value) in scope. For example we have a 4 page task-flow, which has employee search on first page and user can select an employee on first page. After selecting employee user can navigate to page 2, 3, 4. On page 4 we need to know selected employee record.
To achieve this one developer do following
a. Bind employee table of first page on a page-flow bean
b. Bind table with the bean.
c. On page 4, get page-flow bean and then get table and then try to get selected employee row.
Other developer can follow this approach
a. Bind employee table of first page on backingbean-scoped bean
b. Bind table with that bean
c. While navigating to page-2 get selected row from employee table and store its (employee-id or any other needed information) in page-flow scope. If you need complete employee information you can create employee-pojo (object) and set its attribute and then store employee object in page-flow
d. Access employee information from page-flow scope.
[IF you are using bindings and on selection you have selection listener which makes employee row current, you can directly create binding of same vo on page-4. That could be even better]
We see mostly we need to information on different pages, so its better to store those information on needed scope rather than bean.
5. If you really want to store bean in higher scopes: If you really need bean in higher scopes atleast use ComponentReference.
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/util/ComponentReference.html
Disclaimer: Any views or opinions presented in this blog are solely those of the author and do not necessarily represent those of the company.
No comments:
Post a Comment