Rewrite ViewListController to use the core EntityListController

That was a bad title.

Since as of now CMI does not handle UI import/exports, but will in the future, the only part we need is listing, with the operations (hopefully in a dropbutton still, separate issue).

The closest thing to it in core is admin/structure/types.

What would be really great is VBO in core, and a view of views.

In the meantime, #1764194: Convert export_ui to annotations was committed so the current export UI implementation needs to become an annotated plugin.

I hope I get this right on the first try, or the branch tests might fail.

Marking back to active.
http://drupalcode.org/project/views.git/commit/ec66628

Damian started http://drupal.org/sandbox/damiankloip/1778654 and it is AWESOME.

Just to try it out, I went and implemented it for Views.

It's just the listing, so the "add new view" and friends should be moved to views_ui_menu or something.

This is against the 8.x-list-links branch. It now looks exactly like the regular admin/structure/views, which is now at admin/structure/views2.

The only thing missing is the sorting.

I pushed up a branch for this http://drupalcode.org/sandbox/damiankloip/1685040.git/shortlog/refs/head...

Here's a patch too.

Agreed, pushed that up as well.

I'm reasonably sure that #1780396: Namespaces of disabled modules are registered during test runs is causing these error. Added a workaround.

Okay, I reverted the views_api and hook_hook_info stuff for now, that might just have to wait until the sandbox.

views_ui_listing depended only on views, not views_ui

This should make the enable/disable work with AJAX.

Ah! My hack for #1780396: Namespaces of disabled modules are registered during test runs was backwards.
Also commented out the test for 'clone' for now (added a @todo).

Alright, these last 3 were tests for functionality removed in this patch:

• Views Templates
• Importing views
• The filters on the listing page (commented out, not removed, do we want this?)

After spending a good deal of time with this code, I don't actually think that listing should be done by plugins. It should be controllers, like the new form controllers for content entities.

The reason is this: all listing plugins are all gathered, instantiated, and run. Always. If someone wants to subclass ViewListing and use a new one, I don't know how they'd get it to run after ViewListing. Also, the View object doesn't even know that ViewListing exists, only the other way around.

Therefore, I think we should be adding a key like "listing controller class" or "list controller class" to hook_entity_info. ConfigEntityListingInterface can become either ConfigEntityListControllerInterface or just EntityListControllerInterface, because maybe someone doesn't want to build their listing with Views? Who knows.

This is what I had in mind.
Pushed to a new branch 1760284-export-ui-controller in case you guys dislike the idea.

Also attached a patch without the dependencies hack since its not using plugins.

Still too soon to remove that hack, back to CNR for the regular patch.

I debugged that problem. I think.

Merged in! I'll link to the core issue for this when I create it next.

I opened #1781372: Add an API for listing (configuration) entities.
Reopening and postponing this issue on that, we'll need to switch our code over.

Rerolled for upstream fixes

The core patch has noticeably diverged from our implementation. Here is an updated version of it that I think we should commit now, and then the do-not-test patch will be the one to commit later (which will probably still change more).

Whoops, missed a change.

Okay, I merged in #38, and updated 1760284-export-ui-controller with the do-not-test patch. Back to postponed.

http://drupalcode.org/project/views.git/commit/cb54638

YAY! The core patch went in.

7 files changed, 37 insertions(+), 277 deletions(-)
http://drupalcode.org/project/views.git/commit/505fa87