Yet another chart plugin: Announcement and request for further ideas

[Theodor Norup]

After a good deal of frustration with several of the older charting plugins, i've rolled a new hack: https://trac-hacks.org/wiki/TracYetAnotherChartMacro

Design goals:

- Client-side imaging (reduces network load in cases of multiple images and fewer server-side dependencies)

- Allow multiple charts on a single wiki page

- Must work without any configuration

- Jinja2 templating - ready for Trac 1.4

- No Flash

- Should not expose plotly's internal data format but for very special use cases

- Long-term stability:

• do not rely on eg. Google chart API not changing
• possiblity to maintain support for older chart libraries when upgrading to newer libraries
• do not assume that the open internet is accessible

... and maybe even: Allow the older charting plugins to be retired.

Request for further ideas:

I expect to invest some more time in the plugin, so good ideas and suggestions for prioritisation are most welcome.

So far, i have these ideas on my list:

- axis names directly derived from the query

- 2+ data series in the same plot

- configurable standard width/height/colour

- expansion of $TICKET in query text

- better query error reporting

- also use trac's ticket query language

- more plot types. Scatter charts come first to mind

- seek inspiration from MermaidPlugin's trick to avoid the id parameter

- (speculative!) interaction with other plugins. For instance, imagine that TimingAndEstimationPlugin's burndown function could act as a data provider for the present macro - that would on one hand give a nice separation of concern and on the other hand result in a more uniform graphical expression.

Finally, a very valuable contribution would be users' "interesting" (ie. non-trivial) SQL queries - adapted for the most common databases. A single wiki page collecting these would be valuable to many rather than the current scatter.

All the best

Theodor

[RjOllos]

Using Trac's ticket query language and permission restricting arbitrary SQL execution is important for making the plugin widely-useful.

- Ryan

[Peter Suter]

I agree, and assume this would be much easier with ITicketQueryRenderer from #12156. https://trac.edgewall.org/ticket/12156
The plugin could then simply implement ITicketQueryRenderer as shown in the patch there, and users can just use
for example [[TicketQuery(..., format=pie)]] using Trac's ticket query language and so on as usual.
Or is there a problem I'm missing with this approach?

Peter

[RjOllos]

The patches look good to me. I would be interested to see if the timeline format can be added (https://trac.edgewall.org/ticket/12156#comment:5).

- Ryan

[Theodor Norup]

Definitely very neat, but does not fulfil all use cases:

Throughput charts, for instance, represent the count of some event (e.g. ticket closed) per interval of time. That means that you need a data value for each interval in a time range, regardless of whether anything happened in the interval or not. This typically requires use of SQL Common Table Expressions to generate a complete list of intervals to be joined to ticket data. But maybe that could be built into the ticket query mechanism...

If you go for this approach, remember to allow query-specific formatter parameters. Having a few months of experience with Plotly has learnt me that e.g. standard margin sizes are far from one-size-fits-all.

BR Theodor