d8-contrib-modules / views_data_export Goto Github PK

There are 2 reasons to override this display here:

1. The label REST export isn't the most intuitive in the Views Ui. Proposal, stick with the D7 label of Data export.
2. There is no way to attach these views to other displays. There is a core issue, but that could take some time to sort out.

Since this is inheriting from the REST export display, the format selection is using checkboxes. Since this module deals with formatting via config, and subsequently uses a fixed suffix, multiple formats do not make sense. The format should use radio buttons instead.

There's an @todo in the code already, but adding this for tracking.

  // @todo Figure out how to pass this configuration to the Serialization Encoder object.
  // @see https://www.drupal.org/node/2568413.

There are 2 possibilities here:

1. Fake support by just adding a .xls to the end of the file, and ensuring tabs instead of commas are used.
2. Real support by mimicking the 7.x version which simply exports an html table that excel correctly imports as a proper xls file.

The tests from the 7.x version have been lost. This issue is to add some tests back.

-Views is now in core
-Seralization is now in core

Identify gaps with Views to allow for a specific serialization format to be selected as a Views output

-info file
-readme

Corresponding issue to https://www.drupal.org/node/2787209.

The 7.x version of this module supported exporting data via the batch API for large datasets that could not be reliably exported in a single request.

The 7.x version allowed one to specify the resultant file name. For instance, even though the path may be something like nodes/export/csv, rather than the downloaded file just being named csv, the view could be configured to specify a filename. This included token support, so one could have the file name be %view-%date.csv or similar.

It's unclear at this time if this feature will need to go into the csv_serialization module, or here. It will probably be here, and supported by #8.

In this image, the 4 different forms under the Format heading all contain the CSV settings.

I think the issue is in views_data_export_form_alter, it simply alters the form for all forms with the views_ui_edit_display_form.

The fix here is to probably move away from form alters, and use a display plugin type (ResponseDisplayPluginInterface).