ICEFaces request scope (and the consequences)
ICEFaces offers its own interpretation of the JSF request scope : the extended request scope.
This request scope lasts longer than the original request scope: It will continue to live when you are using partialSubmit controls and it will continue to live when you are using non-redirect navigation rules.
This means for example, that when you are navigating back and forth within two pages your beans won´t be recreated which then means that you can´t put code into the constructor of your beans because it will only be executed once.
But sometimes you have the need for backing beans to be recreated every time a page is requested. To avoid having to deal with JQuery you have two possibilities:
What to do when you have a simple ICEFaces application
If you have a simple ICEFaces application that is NOT running in a portlet environment, you can just add a redirect to your faces-config navigation rule:
This redirects to the specified pages, thus leaving the extended portlet request and therefore recreating your managed beans.
This request scope lasts longer than the original request scope: It will continue to live when you are using partialSubmit controls and it will continue to live when you are using non-redirect navigation rules.
This means for example, that when you are navigating back and forth within two pages your beans won´t be recreated which then means that you can´t put code into the constructor of your beans because it will only be executed once.
But sometimes you have the need for backing beans to be recreated every time a page is requested. To avoid having to deal with JQuery you have two possibilities:
What to do when you have a simple ICEFaces application
If you have a simple ICEFaces application that is NOT running in a portlet environment, you can just add a redirect to your faces-config navigation rule:
This redirects to the specified pages, thus leaving the extended portlet request and therefore recreating your managed beans.
No comments:
Post a Comment