-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2012-07-10] Retain pages list view state (pagination, filters) when returning from detail view #503
Comments
comment by: @smagnusson (smagnusson) See also http://open.silverstripe.org/ticket/7647 (when editing a page; the page filter remains from treeview but not listview) |
comment by: @jakr (jak) I think the URL is where this information belongs. Putting that information into the URL and into the history, would also allow to keep track of the last displayed tab. Currently, if you move away from a page and come back with the browser's back button, the tab state is lost along with everything else. Maybe we can find a way to avoid having to reload every time. For things like filtering and sorting it might still be necessary (since applying a filter to a paginated field might show items from pages that have not been loaded yet), but for tabs it would be a pain. |
comment by: @chillu (ischommer) Fixed http://open.silverstripe.org/ticket/7647 by using HTML5 sessionStorage, but only for tab state. |
comment by: camfindlay I have a new use case which bring up the same issue in 3.0.5 for modeladmin. If you open a modeladmin and:
This workflow on a project at the moment has made a lot of extra work for a client that does a lot of sub editing. |
Has any solution to the last point been found yet? I have the same issue described above when filtering in ModelAdmin AND saving the record in the DetailForm (if you don't save the back button and breadcrumbs behave as expected and keep memory of the filter options). I also have a similar issue with GridField pagination i.e:
This results in you being returned to GridField results page 1 of 3 instead of page 2 where you were. I am working on a fix for the first issue (though I don't think its very professional and is a bit of a hack) but don't know where to start with the second. Does anyone have any solutions? Kind regards, HARVS1789UK |
Confirmed still a problem in ss4 |
Any chance this gets looked at some time soon? |
I doubt we'll get around to this before moving GridField into a React component, where that behaviour will be easier to attain (more state managed on the client). If you want to have a crack at it, start with |
Thanks, @chillu. |
This was resolved in silverstripe/silverstripe-admin#1314 |
created by: @chillu (ischommer)
created at: 2012-07-10
original ticket: http://open.silverstripe.org/ticket/7642
Followup from http://open.silverstripe.org/ticket/7589
The pages list view loses its state when navigating into a page detail view, and then going back
via browser back button. This is due to the information being stored in GridState in the PHP session,
associated to the field by a unique ID.
Same problem for ModelAdmin (originally described in http://open.silverstripe.org/ticket/7416 )
There's four different ways we can persist this information. None of them are great.
@Hamish/Stig: Could use some feedback here :)
== Cookies ==
Any state is view specific, so at the least tied to the URL.
This pretty much disqualifies cookie storage, since we'd need to keep too much information.
To illustrate this, if you edit 50 pages in the course of a session (each with a GridField),
you'd have around a 1000 key/value pairs from GridFields.
== URL GET parameter or HTML5 history state ==
URL storage is not as easy as it sounds: The HTML5 History API
forces us to reload a URL via ajax unconditionally.
Take a pagination request for GridField (paraphrased)
POST admin/pages/edit/show/2/field/MyGridField State=&action=next_page
This loads the table only, and advances the current page in the PHP session.
If we push this to the history stack, and a user navigates back to this page later on,
it should load the full CMS view instead of the field, and not advance the current page.
There's history.replaceState(), but it still triggers a reload with the same problems.
Same goes for pushing to the history state object, rather than URL GET parameters.
== HTML5 sessionStorage ==
HTML5 sessionStorage is a more heavy duty replacement for cookies, so still clientside.
So we'd need to wait for the GridField to render, then look up its state ID,
and request the view with this stored state. Not ideal.
== PHP session ==
Still would need to be keyed to the currently viewed URL,
but we can initiate the GridField with the current state automatically without a refresh.
This is not the cleanest solution, but most attractive in terms of loading performance.
Related
The text was updated successfully, but these errors were encountered: