executeQuery.view does an excellent job of updating the page URL to keep track of the current filters, sorting and paging, such that if a user follows a link from the data grid and then uses the back button, the page is the same as when they left it. However, executeQuery.view isn't easy to extend without writing Java code. I frequently use javascript QueryWebParts so that I can easily customize and extend data grids, but my users get annoyed that these QueryWebPart data grids do not nicely retain their state like executeQuery.view does.
Is there some simple way to get QueryWebParts to update the URL to capture the current state of the grid? I understand there is the complexity of needing to deal with multiple QueryWebParts on a single page, but that doesn't seem like a show stopper. I likely can build this out using LABKEY.DataRegion events, but I can't imagine I'm the first person with this need and I'd rather not reinvent the wheel.
thanks,
-Will
|
| |
| Jon (LabKey DevOps) responded: |
2018-06-15 23:37 |
Hi Will,
I don't recall anyone asking about this kind of functionality actually.
When you say the QWP isn't retaining their state nicely when they go back, are you talking about things like Grid Views, sort orders, ad-hoc filters, etc?
Regards,
Jon |
| |
| Will Holtz responded: |
2018-06-16 09:33 |
Hi Jon,
Yes, I was primarily thinking of user applied sorts, user applied filters and current paging (ie, items 101-200 of 533 instead of 1-100 of 533), but the grid view would also be good to maintain.
I would like to achieve the following behavior:
1) on a QWP based grid, the user selects a grid view, filters a column, and adds a sort
2) user moves to second page of grid
3) user clicks on a link within the QWP based grid and this navigates them to a new page
4) user clicks browser back button
5) user returns to exactly the same rendering they were looking at between steps 2 and 3.
Thanks,
-Will |
| |
| Jon (LabKey DevOps) responded: |
2018-06-22 18:00 |
Hi Will,
Thanks for the clarification.
This would definitely be a feature enhancement on our end to change the behavior to where it doesn't default back to the original hardcoded QWP.
I'm not certain whether this has been asked previously, but I'll submit this for a future review.
Regards,
Jon |
| |
| Jon (LabKey DevOps) responded: |
2018-06-22 18:43 |
|
| |
|
|