Replace hard-coded tables with views

In a related issue, RedEight said (of the Results / Table):

If we implement this in views, should we add a new _webform_view_component hook for views displays? Or would we modify the reports page to entirely use views? Both?

I haven't looked at it closely enough to be specific, but I think each component should be called in turn to add it's fields to the view. The reports/ table would use views exclusively (the way I am envisioning this).

I'm not very keen on adding an additional setting to every component to control whether it is shown in the results table. I was more thinking of an alter function allowing developers to program this to their needs (which may well depend upon role and other factors).

We also need to take care with backward compatibility. Unless we defer this to weform -5.0, which I don't want to, we need to allow existing components to have their column. Therefore we need to be careful about how any additional fields in the component info table is created and used.

If this data were in the info table, then it would be used. And in its absence, whatever field webform uses today would be added.

I'm not sure we want to control the columns in views. This would mean that possibly a different view would be needed for every webform.

I was more thinking of something like HOOK_webform_results_view_alter(). But I have not given this deep thought.

Update: I've been working on the results table. I have an implementation that uses a combination of an initial view, some enhanced handlers, and some code that modifies the view for the webform's components and pager.

I suspect that the analysis is beyond the scope of what we can do with views.

This would constitute an API change because of the theme functions would no longer be used. I am thinking that we need to deprecate the existing hard-coded tables and theme functions. An update function would set webform to use the deprecated functions but new installations would use views.

I plan to more forward, taking advantage of the work that RedEight did on the submission table.

FOR DISCUSSION:

I am thinking that I need to make a "legacy.tables.inc" and a "views.tables.inc" that each implement the same functions and include whichever one is selected via an admin form. If there is ever a 7.x-5.x, the legacy functions would be removed. New installations get views; existing sites get legacy via an update function.

I think If people have themed or used hook_menu_alter to modify the tables, their changes won't work with the new views implementation.

This path is for testing and comment only. It is not complete and should not be used for production.

Views support enhancements:

1. A views area result handler has been added that can mimic webform's items-per-page controls. It also can supply tokens from the first row of the results.
2. A new expanding field which expands to create a field (and column, if placed in a views table) for every component.
3. Ability to use the webform node id as a filter, sort, and argument.
4. Ability to use the webform submission user id as an filter and be included as a field.
5. Enhanced view, edit, and delete links, including the ability to display the serial number/ is_draft status, proper access checking, and click-sorting (useful when displaying the serial #)

Actual views

1. A webform_submissions view that can replace the existing submissions table (SUBMISSIONS tab).
2. A webform_results view that can replace the existing results table (TABLE tab).

API enhancements

1. When a view is expanded to show all the components, hook_webform_view_alter provides modules an opportunity to modify its additions to the view.
2. Components can now implement _webform_view_field_COMPONENT to modify the fields that are added for that type of component.
3. Views support has been upgraded from views 2 to views 3.

Bad API example.

Again, another patch for comment. This patch:

1. Fixes an issue with clearing the cache and loading the default views.
2. Fixes the items-per-page links
3. Allows site builders to customize which view definition is used, by node id or node type. For example, a view with a machine name of 'webform_results_123' would be used when node nid == 123 is having its data report viewed.
4. Loads the webform-admin js and css files, the only part of which is actually needed is to bold the current number of items-per-page. I am sorely-tempted to just surround it with bold html tags. I bet no one customizes the appearance of the current number of items in the reports.
5. The new views-based reports are used unless the variable 'webform_table' is set to a truthy value. I decided that if you want the old deprecated behavior, you'll have to ask for it, even if you upgrade. We will need an application / upgrade note for this.

Comments would be very helpful.

Committed to 7.x-4.x. This patch does not apply cleanly to 8.x, at least in part due to a webform.info hunk.

... it makes sense to drop the backwards compatible non views versions for D8.

Absolutely!