Suggestion for re-architecting this module to become even more versatile [#2076413]

Hi Jon,
Thanks for this module! It works a treat.

There are a number of modules in Drupalland that like DataTables implement the Views Style Plugin. For instance:

They're all lovely modules, but due to the fact that Views Style Plugins are mutually exclusive none of these can be used together on the same View.

I'm particularly interested in using DataTables with Views Aggregator Plus on the same View.

What I'm thinking as a solution is for DataTables to shift all the configuration it currently puts in the UI of the Views Style Plugin to a generic DataTable configuration UI page (eg at admin/config/content/datatables) with a selector for the View(s) at the top of it. That way the DataTables module is no longer exclusively hogging the Views Style Plugin, leaving that spot available for other modules that REALLY need it, like Views Aggregator Plus, which uses the Views Style Plugin not just for its UI, but also to post-process the data returned from the database, server-side.

With the configuration outside of Views it should also allow DataTables at some future point to operate on tables on the site that aren't generated by Views, e.g. web form submissions or a table a copy-writer inserted inside normal node content.

Your thoughts?

Best,
Rik de Boer
maintainer of Views Aggregator Plus

Comments

Comment #1

herd45 CreditAttribution: herd45 commented 29 August 2013 at 11:02

I would add that if the settings are moved to configuration, there needs to be a way to create different Datatables configurations and assign them to different Views displays. For instance on the config page you would create and name multiple datatables configurations, and then on the views style settings form you would choose one of those configurations.

Comment #2

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 29 August 2013 at 11:46

@herd45:

Yes something along those lines.
However you wouldn't have the View Style Plugin settings as that would defeat the purpose of the re-architecting proposal.
Instead I suggest we divide up the configuration page into fieldsets. Each fieldset would prompt the user for a set of configurations PLUS a multi-select box (or series of checkbox) to select which Views the configuration fieldsets would apply to.
So you'd have:
DataTables configuration fieldset 1: this and this and this DataTable setting: assigned to View name#1, name#5
DataTables configuration fieldset 2: that and that and that DataTable setting: assigned to View name#3, name#4, name#9

A future extension would be to allow specific nodes (that have tables on them) to be assigned to a configuration fieldset, thus broadening the magic of this module to ANY page on your Drupal site, not just View pages.

Rik

Comment #3

herd45 CreditAttribution: herd45 commented 29 August 2013 at 12:12

I figured that the option to choose the datatables configuration could be included in the regular table style or other table style plugins.

Your solution also works. Although it would be more flexible if configurations were matched up with displays, as opposed to being matched with the whole view.

Comment #4

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 29 August 2013 at 12:32

@herd45, #3

"I figured that the option to choose the datatables configuration could be included in the regular table style or other table style plugins."

From a UX perspective: totally agree. From a developer perspective.... maybe... Views gives us a particular extension framework and your solution would be bending the Views conventions somewhat...

"Although it would be more flexible if configurations were matched up with displays, as opposed to being matched with the whole view."

Spot-on there! Yes, DataTable configuration sets would ideally apply per View display, rather than all of the displays of a View.

Rik

Comment #5

duellj CreditAttribution: duellj commented 19 September 2013 at 20:25

@RdeBoer, @herd45,

Thanks for suggesting this, I am interested in the possibility of abstracting out DataTables, but I'm not quite clear on the specific use case with views (though it would be nice to be able to attach to any table on the site, but that's a complicated issue). DataTables requires specific markup and takes over most of the table with JS, so I'm not sure if it would even play nicely with these other views styles mentioned in the ticket. I also don't like having to manage settings separate from the views settings.

Plus, DataTables has it's own aggregation and summary handling that would override these plugins (once we get them in). Also, once AJAX is fully functioning for the module all integration with other style plugins will break.

I'd be happy to be convinced to include this with a good argument and/or a working patch :).

Comment #6

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 20 September 2013 at 08:12

@duellj
Thanks for at least considering this.

The aim of this is not to make DataTables work with ALL other Views modules operating in this space. As you say some of these module may have conflicting functionality anyway, so cannot logically be used together.

The aim is to rewrite the configuration code so that it doesn't unnecessarily hog the Views Style Plugin, leaving that space for modules that really, really need to use it. Views offers only one style plugin.

If you don't want to move the config out of the Views Style Plugin (which would be necessary if at some point you want this module to operate on any table on the Drupal site, not just Views tables), then maybe we can follow the path suggested by herd45, i.e. to implment hook_form_alter() on the Views form, rather than implementing the Style Plugin.

Cheers,
Rik

Comment #7

duellj CreditAttribution: duellj commented 20 September 2013 at 16:34

@RdeBoer,

A form_alter on the style plugin form sounds preferable. herd45 mentioned that he is going forward with a patch for this issues, so let's go forward with that path.

Thanks!

Comment #8

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 20 November 2013 at 11:58

Time has passed and for me the issue has risen again...

I have use-cases where I wish to:
o apply the power of DataTables JS to any table, not just Views tables
o use DataTables JS in combination with any Views plugin, rather than exclusively using the DataTables, which excludes using other Views plugins
o employ the DataTables JS responsive extension (FooTables style)
o configure all of the above on any table -- many tables on a Drupal site are not generated by Views, think of Field List, Recent Log Msgs, Content etc...

I have thought long and hard about this issue and have been in debate with herd45 too.
I prefer not to launch a similar module.

But considering my own and the maintainer's constraints in #5, I can't see how any patch to this lovely module would implement my (and other people's) use-cases while continue to support existing installs.

So as this module is architected for a subset of what the DataTables JS library is capable of and I need DataTables JS for the other subset of its capabilities, I may develop my own solution, one that does not prevent users from using any Views plugins.

I believe there's a place for both modules to live happily side by side. Horses for courses.

Thank you so much for your inspiration!

Rik

Comment #9

Shawn DeArmond CreditAttribution: Shawn DeArmond commented 2 May 2014 at 15:49

+1 for responsive tables!

Comment #10

Elin Yordanov CreditAttribution: Elin Yordanov commented 25 June 2014 at 14:07

Why not we create a new branch for 7.x-2.x and start to "rearchitect" the module in the way @RdeBoer suggest, and see how it works?

If it works as planned, then an upgrade path could be written in an update script.

Comment #11

duellj CreditAttribution: duellj commented 25 June 2014 at 16:19

Good idea, pc-wurm, thanks for jumping in the queue to help out on issues! Feel free to open up the new branch and start the process. I'll try and help out where I can.