Problem/Motivation

When the 2.x branches were created, Views integration was not the main focus. See #1507800-5: Views-independent Highcharts API.
However, this is an important part of this module, and one we'll be using a lot more.

Proposed resolution

Views integration in the 2.x branches of Highcharts need to be refactored.

In general, the goal of Highcharts views is to use Views as a data provider and UI for creating Highcharts. And in particular, to allow Views UI to make full use of the Highcharts library options.

Status

There are a number of interrelated tasks and existing issues with Views integration in these branches, which we can use this issue to track.

Structural and views integration issues

#1547090: Autoload files
#1561694: Highcharts views theme functions and templates
#1697274: Allow charts to work with AJAX - For AJAX-enabled views
#1697276: Allow Highcharts views to render large datasets
#1466050: Accessing the Highcharts themes - Consider how or if this could be a setting for Views. The issue is Highcharts themes only work per page, not per-chart (but there may be multiple blocks per page).

Highcharts library Options selection

#1674928: Allow full use of Highcharts library Options in Views
Once this is addressed, the following existing issues should also be fixed:

Comments

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Issue summary: View changes

Updated issue summary. Removed an issue that only applies to 1.x.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Issue summary: View changes

Tied issue #1674928 to existing options issues

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Issue summary: View changes

make the parent-child relationship between issues more visually obvious

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Issue summary: View changes

Updated issue summary. Added additional issues

kpa’s picture

kpa commented

Hi,

Is there any reason that this module is limiting to Fieldable entities only? IMHO, the plugin style should be able to render any format of output - whether or not the view is using entities, and whether or not the view is using Fields on that entity. It seems a very strange design decision to purposefully limit the usefulness of the module to entities only?

Even straightfoward entities such as 'node' - you wouldn't be able to use this Views integration to show properties of the entity.

This feels more like a sandbox, built to address a specific use-case, than an abstract API that is packaged as a module for all to use.

Would appreciate an insight into the rationale.

Thanks

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

@kpa Your comment only applies to the 1.x branch – this issue is about the 2.x branch. Make sure to read the description of each branch on the project page, and look at the status of these issues. The Views integration as developed in the 1.x branch was always limited, and to me not worth continuing. This issue was/is for tracking more robust, generic Views integration for the 2.x branch, which is a Drupal/php API wrapper for the Highcharts JS API – however, there is one main issue that needs to be solved before 2.x Views integration is useful #1674928: Allow full use of Highcharts library Options in Views (I have outlined this in detail there, but have not had time to work on it for a few years now). One valid point I can see coming out of this though is that this module is not really actively maintained anymore – I have changed the status on the homepage to seeking co-maintainers. But please keep each issue in the queue on topic.

kpa’s picture

kpa commented

@scottrigby I'm actually using the 7.x-2.x-dev codebase for my project, though I've had to write the Views integration myself, as the packaged version doesn't work unless you're using a View with a single entity, and fields.

I'm looking specifically at the docblock for ViewsHighchartsOptions::getFieldAllowedValuesResultCount() or ViewsHighchartsOptions::getFieldAllowedValues() which shows that you've at least thought about the possibility of more generic use cases. Whilst the module works for fieldable entities, this is not how Views works - our need was for a more generic Views integration, to be able to create a graph/chart from any data, including properties on a custom entity, or even custom data.

Requiring the use of your own field_analytics module is also bad practice - there should be no reason for Views Highcharts module to rely on any field modules.

Once I've finished my project I'm happy to tidy it up (currently still a work-in-progress) and commit it back as a separate branch/sandbox for you to review - but it's substantially different from the direction your module is going in. Given this, I was wondering why you approached the module in the way that you did, as it really limits the usefulness of the module?

Thanks!

monaw’s picture

monaw commented

Where can I download a compatible version of the highchart javascript library that's needed for this module? I went to the highchart site but can only find the highchair.js file (https://code.highcharts.com), not the other needed files