RFC 82: Treeless page listings #82
Conversation
|
Design references from elsewhere in Wagtail: ModelAdmin flat page listing
ModelAdmin "choose parent page" step
Report with filters
|
|
Looks good! Do we want to combine them with page based |
|
|
||
| ## Specification | ||
|
|
||
| A `register_page_listing` function will be provided, similar to the existing `register_snippet` and `modeladmin_register` functions, which is passed a class containing configuration options and creates a listing view according to those options. Typically this would be placed in a `wagtail_hooks.py` file and look something like this: |
There was a problem hiding this comment.
Can this RFC be joined up with wagtail/wagtail#8609, or at least reference it?
There is a big discussion around
We want to have a single, "definitive", way to manage Django models in Wagtail Admin
This feels like a specialised subset of that. Are we introducing yet another mechanism of doing things?
There was a problem hiding this comment.
@zerolab That's a really good point! Having discussed with the design team just now, we've agreed that it makes sense to shift away from thinking of this as a Modeladmin-esque "bolt-on" feature, and more a new mode of behaviour for the standard page listing view. And indeed, as snippets grow to take on more of the feature set of pages (essentially everything except the tree structure), the distinction between "pages presented in a tree-less view" and "a listing of snippets" becomes increasingly moot.
So maybe the real task here is: redesign the generic index view to the point where we can acceptably use it for page listings, and implement tree-based and tree-less as different modes of that.
There was a problem hiding this comment.
This has also sparked a side discussion about whether the pop-out page explorer has outlived its usefulness - it's effectively become a "more instantly accessible" version of the listing views, and having the listing views themselves take on that role is really just* a matter of performance and nice UI transitions. Suppose the new out-of-the-box behaviour becomes "click Pages in the menu, and get a pop-out transition that lands on a full-page listing with all of the filtering and actions described here, and controls to switch between tree-based and tree-less" - that neatly eliminates the duality between explorer menu and explorer views, and makes the Pages menu item less of a special case. And then if a developer decides that their Pages menu is better off being tree-less by default, or that they should have a distinct "Articles" menu for one page type, that's just a matter of customising the menu. Or to put it another way: the default Pages menu item is nothing more than the out-of-the-box setup of a PageListing config as described in this RFC.
- OK, the "just" might be doing a lot of heavy lifting here :-)
|
|
||
| Initially the listing is ordered by most recently updated first, but this can be changed by clicking on the column headings. | ||
|
|
||
| Alongside the listing, various filtering options are available - these will immediately refresh the listing on change: |
There was a problem hiding this comment.
What is the plan for the filters, design wise?
Will they be similar to https://user-images.githubusercontent.com/85097/213148970-ed8dec23-1f66-449f-8eb8-c9d8f2a3d02a.png (from the design references comment)? I recall there was a plan to overhaul that as the sidebar filters can get unwieldy int heir current form
|
After iterating on this with the design team, the focus of this feature has now shifted considerably away from a ModelAdmin-like view existing as its own menu item, and towards enhancing the searching / filtering capabilities of the main explorer view - this would then incorporate the ability to switch between a tree-based representation and a flat page listing. As such, I will create a new RFC to replace this one. |
|
Just a heads’up for people interested in this that we have a new Discussions thread about this: Universal listings (search and filtering) #10446. As @gasman mentions, those latest designs are much more of an iteration on Wagtail’s current listings. hence the "Universal listings" rename. |
In many situations, the standard tree-based page explorer is not the ideal interface for editors to find pages of interest. For example, a newspaper site might organise its articles into sections by topic - if an editor works across multiple topics and wants to find a draft article they were working on yesterday, they would probably prefer a flat listing of all their articles ordered by recency, rather than having to remember which topic the article was filed under and seek it out in that section.
This RFC proposes a mechanism for setting up a listing view in the Wagtail admin that displays all pages matching certain criteria, as a flat list. This will be similar to the index view provided by the ModelAdmin module when used with a page model, but will not be restricted to a single page type, and will provide more flexible filtering options.