ADF UI table pagination and ADF BC range paging sounds like a perfect combination. But to make it work perfect, a bit of extra effort is required. In the case of search/edit implementation, it can't remember updated record when navigating back to search screen (VO runs with Range Paging and UI table is displayed with pagination). I will explain how to solve it and show how to keep UI table displaying current page and prevent jumping to the first page.
Here is the working use case (download sample application - SearchEditApp.zip). Navigate to any page except first in UI table and select a record:
On edit, selected record should be opened in the fragment. Both buttons Save and Close/Close would return back to search screen, where current record and page should be preserved:
Close button will trigger Rollback operation, but current row should not be lost (see solution here: ADF Rollback Operation and Stay On Current Row):
Current row and page remains selected on return to search fragment:
Huge advantage of Range Paging mode for VO - faster navigation between UI table pages. This is especially important now, when we support pages. It is much easier for the user, to navigate to the last page (one click, without scrolling). We must ensure fast navigation in the table. This can be achieved with Range Paging - it will force VO to generate SQL query with ROWNUM and what is also very important - it will fetch only a subset of data (by default, ADF BC would fetch all rows until last, when navigating to the last page). Here we navigate to the last page:
Example of SQL query generated by VO enabled with Range Paging and subset of row data fetched for last page:
To force UI table to return display to correct page (navigation to search from edit), when Range Paging is enabled in VO - make sure to set first property for UI table (see solution here: ADF Rollback Operation and Stay On Current Row). We should keep track of current range start before navigating away from search screen and reset it back to the same value, when navigating from edit. I'm keeping this value in pageFlowScope variable managed through the bean method invoked on edit:
This is the method - it keeps track of current range start and updates pageFlowScope variable (later referenced from first property on UI table):
Bonus - see example how to refresh VO data (this is useful, when you want to display latest data to the user, before he starts editing it) and keep current row. When Range Paging is enabled, current row can be retained by re-setting current row key obtained from iterator binding (this executes SQL with find row by key and returns only current row):
Here is the working use case (download sample application - SearchEditApp.zip). Navigate to any page except first in UI table and select a record:
On edit, selected record should be opened in the fragment. Both buttons Save and Close/Close would return back to search screen, where current record and page should be preserved:
Close button will trigger Rollback operation, but current row should not be lost (see solution here: ADF Rollback Operation and Stay On Current Row):
Current row and page remains selected on return to search fragment:
Huge advantage of Range Paging mode for VO - faster navigation between UI table pages. This is especially important now, when we support pages. It is much easier for the user, to navigate to the last page (one click, without scrolling). We must ensure fast navigation in the table. This can be achieved with Range Paging - it will force VO to generate SQL query with ROWNUM and what is also very important - it will fetch only a subset of data (by default, ADF BC would fetch all rows until last, when navigating to the last page). Here we navigate to the last page:
Example of SQL query generated by VO enabled with Range Paging and subset of row data fetched for last page:
To force UI table to return display to correct page (navigation to search from edit), when Range Paging is enabled in VO - make sure to set first property for UI table (see solution here: ADF Rollback Operation and Stay On Current Row). We should keep track of current range start before navigating away from search screen and reset it back to the same value, when navigating from edit. I'm keeping this value in pageFlowScope variable managed through the bean method invoked on edit:
This is the method - it keeps track of current range start and updates pageFlowScope variable (later referenced from first property on UI table):
Bonus - see example how to refresh VO data (this is useful, when you want to display latest data to the user, before he starts editing it) and keep current row. When Range Paging is enabled, current row can be retained by re-setting current row key obtained from iterator binding (this executes SQL with find row by key and returns only current row):
Hi Andrejus,
ReplyDeleteThanks for your post. We have used your solution in our project with JDev 12.1.3, but we have a situation that we can't resolve.
When you search and select a row in the page 4, when you do another search, the current row moves to first row but the af:table remains in page 4...
When we try to initialize pageFlowScope.rangeStart to 0 and refresh the af:table, the navigation page doesn't move...When we do a complete page refresh it works, but the visual effect and UX is horrible...
Do you have any solution for this?
Thank you in advance.
Hi,
ReplyDeleteI am also facing the same issue but in different scenario. Did you find any solution to move the pagination to the 1st page.
Thanks,
Gokul
Sorry, I cant reproduce it in 12.2.1.2. It works as expected in our production system.
ReplyDeleteYou could send me sample app by email, I could check it out for you.
Andrejus
Hi Andrejus,
ReplyDeleteDo you think it will work in the version 11.1.1.6.0?
Thanks,
Rahul
No idea, 11.1.1.6 is so old version.
ReplyDeleteAndrejus
Is the sample application incorrect one? The EmployeesView VO in the SearchEditApp sample app is configured with Access Mode as Scrollable rather than Range Paging. Further, the search results table (af:table) in emplsSearchView.jsff does NOT have its ScrollPolicy set to Page.
ReplyDeleteUI table is set with scrollPolicy="page". Yes, VO is not set with Range Paging, you can set it - probably I removed this setting during last testing.
ReplyDeleteAndrejus