Example of Changes

We use it heavily in custom application work. Views has a bit more restrictive structure that would not allow for that sort of display.

In particular there are items attached to Commerce's data field which are then stored via BLOB and not via fields. In our scenario you are talking about having hundreds of input points from across entities which views would render huge performance issues in that regard or the need to manage hundreds of fields within views. It is easier in scenarios with larger data points / sets to compile the information on the backend then have it render through the page controller to the graphical receiver (Charts in this case).

I'd be happy to walk you through offline if you would like as I am not able to post code for this particular project.

With that said, it is probably correct to be focused on the views integration at this point as it will satisfy the majority of use cases for most individuals using the module. However, I will say that the ability to call charts outside of views has allowed us to achieve some pseudo big data analysis and displays that are not achievable elsewhere without the direct importing of a charting library which tends to be messy when dealing with those large data sets as they all require the direct injection of script.

Think of instances where data is sensitive and cannot be stored via Drupal to begin with or where it is dynamically received remotely.