In doing the Twig conversion, we are moving many concatenation-based theme functions into templates. Some of these are for administrative forms, which are based on tables.
Most of these follow a similar design pattern:
HEADING
-------
[ Global operation button(s) ]
[ Filter form ]
[ Operations form ]
[ Show/hide details link ]
+===========================================+
| HEADING | HEADING | OPERATIONS |
+================+=============+============+
| Foo | Oof | edit del +
+ ---------------|-------------|------------+
| Bar | Rab | edit del +
+ ---------------|-------------|------------+
| Baz | Zab | edit del +
+===========================================+
[ Global operation button(s) ]
This pattern is similar to what we sometimes accomplish with http://drupal.org/project/views_bulk_operations
Below are some URLs in core where these exist (this is not an exhaustive list).
/admin/content
/admin/content/comment
/admin/structure/types
/admin/people
/admin/people/roles
/admin/config/content/formats
/admin/config/media/image-styles
/admin/config/regional/date-time
/admin/modules (similar)
Many of these provide a theme function to style the form they use. It seems better that we should provide instead a consolidated "administrative interface" theme component so that we can reduce the duplication in the theme system
Comments
Comment #1
c4rl CreditAttribution: c4rl commentedTagging
Comment #2
tim.plunkettI'd like to think that this is a duplicate of #1864980: [meta] Figure out how to integrate Views into core / #1823450: [Meta] Convert core listings to Views.
Dries has decided that these listings should be views, and we're working on converting them.
I'd hate to see any work done to convert them to Twig, only to have that work ripped out.
Comment #3
catchThere's also #1876712: [meta] Convert all tables in core to new #type 'table'.
Comment #4
tim.plunkettEverything on that list that isn't getting a View should get a ListController, like #1872870: Implement a RoleListController and RoleFormController
Comment #5
tkoleary CreditAttribution: tkoleary commented@tim.plunkett
Just out of curiosity why not make them all views?
Comment #6
tim.plunkettUntil Views has an entity_query backend, it cannot list anything stored as a ConfigEntity (image styles, menu links, text formats). There are many blockers for that to happen, which are spread across several issues. But when it happens, it will be easier to transition a ListController into a view than the custom code anyway.
Comment #7
tkoleary CreditAttribution: tkoleary commentedGood to know. thx
Comment #8
c4rl CreditAttribution: c4rl commentedYeah, my purpose with opening this issue is to acknowledge the design pattern, and whether the backend is driven by views or some other controller, perhaps there's some common ground.
Nevertheless, I don't wish to shoehorn administrative UI into something that isn't appropriate or flexible, but at minimum we can reduce the UI duplication.
Comment #9
tkoleary CreditAttribution: tkoleary commentedLinking #2022297: [META] Unified toolset for Views in core since it's a similar concept, if more UI focussed
Comment #10
joelpittetThere are lots of admin views now, we are in RC, bumping this to 8.1.x if someone wants to create a component for this.
Comment #12
joelpittet