There are two main keys to this technique. The first is to not expire the managed bean of the view with the pageFlow. The second is to keep a member variable of the current index of the table.
Expiring Managed Beans: In the sample project, open up the Faces Config Editor and select the bean: PagingPortletDefaultviewView. You’ll see that the value for the expireWithPageFlow is set to ‘false’. This instructs MWS to keep the managed bean valid until the user’s session expires.
Preserving the current index: Open the Paging Portlet’s Default View and see the currentIndex member variable. This is bound to the Async Table’s First property. That property is the index of the first item to display.
Please see the attached sample project. To use it, after deploying browse to the Public Folders and then the “paging folder”. Page through the list and click on the links in either column to see state passed to the view and/or portlet and then click back. You’ll see the paging state is preserved.
Hi Mark,
I understand that if we set expireWithPageFlow to false then the view’s managed bean is not reset and holds the variables. If there are huge lists having 100 of rows and the number of users using this view is more than 500, what could be the impact of server memory and performance
We’ve already implemented setting the expireWithPageFlow to false and ran into many issues with the resetting variables declared in the view file.
If the view for which i’m changing the page flow setting is the default view of the portlet and if i navigate to this portlet is there any way i can reset these values. My guess is that page flow setting overrides the initialize method of the view.
Forgot to add one more issue related to pagination.
We faced an issue related to pagination whenever the number of rows in the table are less than the value of the first row, it shows Beyond End of Data in place of pagination and doesnt show any results.
I’m not sure how you get in this situation. Does that mean that the user was on page 5, but now there are only 4 pages of data? Well if so, i would put some logic in the getter to check for this error condition and if detected set the page index back to 0.
That’s a great description of why you should always execute adequate performance testing prior to putting your app into production. That is the best way to answer your question.
I’ve downloaded your example and I saw the pages working.
I’ve to do the same, when the user click in a link, he goes to another view, and than when he click to return (new action) the async table has to be in the same page.
In your example, I can’t see where you link “Current Index” to your async table.
Can you please explain how you did the second part?