Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The d3 module views integration is confusing and not very extensible. It was built on the assumption that your data was going to be in a specific format for charts like a line graph.
I propose a model that might not be less complicated, but a little more extensible and something that we can build documentation on.
All libraries will need a "views_data_fields[]" array in the info file to define or customize the data sent to the visualization.
views_data_fields_key = rows ; will define what the array will be called, this defaults to rows.
views_data_fields[rows][field_name][label] = Human readable label for views integration
views_data_fields[rows][field_name][type] = Field type, these will need to be defined somewhere
views_data_fields[rows][field_name][description] = Regular description for views UIThis can also be written as:
views_data_fields[rows][field_name] = { label: Human readable label..., type: Field type, description: Regular description for views UI }
Other data can be mapped as well, for example
views_data_fields[legend][field_name][label]
...
This will allow a visualization to use data outside of the rows array, which might not have certain labels or names that will be needed in a key/legend.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2279815-whitespace-interdiff.diff | 2.2 KB | drumm |
| #12 | improve-views-2279815.patch | 41.51 KB | asherry |
| #8 | improve-views-2279815.patch | 41.15 KB | asherry |
Comments
Comment #1
asherry CreditAttribution: asherry commentedComment #2
asherry CreditAttribution: asherry commentedComment #3
joehudson CreditAttribution: joehudson commentedHappy to hear the patch is coming soon. I'm wanting to use the forcedirected graph functionality of d3 together with views. But the current implementation doesn't allow for that. Will the patch do so? Otherwise, I'd appreciate some tips of what would need to be done with the module to allow this.
Comment #4
asherry CreditAttribution: asherry commented@joe are you talking about the forcedirected graph library that ships with the d3 module? I actually didn't plan on integrating that with views out of the box because I think people are already using the graphapi to do that.
If you'd like to work on integrating it directly with views though I can steer you in the right direction. You'll probably have to add in a few lines to the .info file and then do some testing, maybe even come up with an example that can ship with d3.
Comment #5
joehudson CreditAttribution: joehudson commentedYes, I want to use d3 with views for forcedirected graphs. It looks like the graphapi doesn't support d3 directly. If you think it's more sensible to tweak the d3 module for this functionality, then yes please, do give me some pointers. Otherwise I'll look more closely at graph api. Thanks.
Comment #6
asherry CreditAttribution: asherry commentedIt's the other way around, the d3 module has built in support for the graphapi module.
Comment #7
joehudson CreditAttribution: joehudson commentedOk, so what would you say would be the most sensible way of going about being able to select some fields to be grouped into graph nodes and some entity reference fields for links from within views, and format them so that the js d3 library can render a forcedirected graph? Make changes to the d3 drupal module, and/or the graphapi module? Any guidance would be much appreciated.
Comment #8
asherry CreditAttribution: asherry commentedHere's the first patch. This should bring up some new options in the views settings allowing somebody the ability to map fields from views to their visualizations.
Comment #9
asherry CreditAttribution: asherry commentedJust a note, you'll need to patch the git repository on the 7.x-1.x branch, not the actual package. Otherwise there will be a conflict with the library packaging information in the .info files.
Comment #10
asherry CreditAttribution: asherry commentedComment #11
asherry CreditAttribution: asherry commentedNew patch, fixed field error "Error: numeric field required for integer type".
Fixed whitespaces in patch.
Comment #12
asherry CreditAttribution: asherry commentedComment #13
asherry CreditAttribution: asherry commentedComment #14
drummAttached is a patch to change tabs that crept in to spaces.
Comment #15
asherry CreditAttribution: asherry commentedAnother substantially large commit. Please check the improve-views branch rather then a posted patch.
What we have now is classes for handling all parts of the info file. There is a controller, a processor, and a mapping class. The info hooks now will allow other modules, (d3_views) to add their own classes.
What we can do now is parse out info files in a more advanced way. Fields can now have meta data in addition to field mappings.
views[fields][rows][field_name] = { label: My field, description: My description, __meta_key: meta value }
views[fields][rows][__data_type] = 2dnnv
All metadata values will be parsed into a single [_info] array to check easier in code. Also check for more info now in the d3_views.api.php file.
Comment #16
drummThis looks like it is running up against the limits of the .info format. A possibility would be using the Yaml format.
An example of a D7 module doing this is project_dependency, http://cgit.drupalcode.org/project_dependency/tree/project_dependency.dr.... The parser is included in https://www.drupal.org/project/symfony. That may make d3 module harder to install on D7, but it will make a lot more sense in D8 and make D3LibraryInfoProcessor more simple.
Comment #17
asherry CreditAttribution: asherry commentedNeil I definitely agree with you, it is running up against the limits. Switching over to a dependency on symfony (in d7) and a complete rewrite of the architecture at this point though seems like it would do more damage to the timeline and overall ease of module install then it would help in future functionality additions.
I'd say maybe that's a great idea for the 2.x version, but honestly it's hard to say that with a straight face when there isn't even a real 1.x version yet.
I am planning on utilizing yml technology in the d8 version though, it seems like the release and adoption of drupal 8 will be the right time for this module to bloom. Also, by then, the concept of this module hopefully won't be so new, and many more developers can extend on the yml and library functionality.
Comment #18
clemens.tolboom@joehudson Graph API support d3js as you can see from the new issues I posted for d3. If you enable d3 and graphapi_demo you may visit http://drupal.d7/admin/config/system/graphapi/demo
Comment #19
clemens.tolboomWhat I did in Graph API is let the diagrams / providers decide what they support through graphapi hooks.
With d3js it is possible to create a zillion diagrams based on graph or table data. But the visualization decides whats available: axis type, hover info, click behavior, etc.
Let users change the config alone is not enough as they need to change the js implementation too.
Lately I ran into https://www.drupal.org/project/visualization and https://www.drupal.org/project/charts_graphs of which the latter claims to support d3js. Need to test both (and others) to reconsider Graph API and D3 efforts.
Comment #21
asherry CreditAttribution: asherry commentedLet's consider this done, @clemens.tolboom we can move onto your issues in the other threads. @drumm makes a good point, this will lay the groundwork for the 2.x version (for drupal 8).