Adding plugin capability to flot

[GoogleCodeExporter]

In order to make it easier to extend the capabilities of flot (adding 
logarithmic axes, trend lines, 
drabability, etc.) and ease the burden on developers and not bloat the flot 
code, I would like to 
propose extending flot to support plugins.  The changes to flot code itself are 
very minor and I've 
attached a patch file.

Conceptually, the changes to the flot code are:

* Expose more instance properties/methods on the Plot object itself.
* Encapsulate the bulk of Plot initialization in an init() method which can be 
called at the 
appropriate time.
* Create a $.plot.plugins array to hold registered plugins, then cycle through 
the plugin's init() 
methods before Plot initialization (during the $.plot() call).

These changes, as shown in the patch file, involve a few dozen lines of code.  
There may be 
some additional properties/methods that need  to be exposed which I haven't 
considered yet.  

The drawing routines of Flot are not exposed.  This could also be considered, 
which would allow 
custom plot types (bubble charts, candlestick charts, etc.) to be developed as 
plugins.

Also attached is a sample plugin for logarithmic axes.  This is a port of 
Jonathan Leto's 
logarithmic axes mods.  It is unpolished and pretty rough, but could be 
considered as a possible 
template for plugin development.  The approach I took was not to monkey patch 
flot methods, 
but to use a decorator pattern.

Plugins could be developed in whatever style a developer wishes.  The only 
requirement is that 
the plugin have an init() method which takes a Plot object as its argument.  
This method is called 
by $.plot and it must return the modified Plot object.

I appreciate any feedback on this idea and comments/criticism on the approach 
I've used.  I hope 
it is a reasonable modification and could be included in the flot code.

Original issue reported on code.google.com by chris.le...@gmail.com on 14 Mar 2009 at 3:52

Attachments:

• pluggable-r147.patch
• flot.logAxes.js

[GoogleCodeExporter]

I wrote a comment previously this week, but unfortunately code.google.com ate 
it (I
hit a scheduled downtime).

I think your idea is interesting, also because it is very simple. The main 
downside 
is that it doesn't address API compatibility and plugins stepping on each 
other's toes.

I guess the question I'm pondering is what is the anatomy of a plugin, and does 
it
require us to expose all of Flot or would some hooks be enough? Well-defined
semantics makes it easier to control API compatibility.

I'm thinking that when I do a plugin, I want to add some options, maybe hook 
into
data processing, axis layout or drawing, or the interactive functions. So if 
hooks
with well-defined semantics were available it'd be easier to do. Or maybe the 
simple
model of yours is actually easier to understand because everything is in the 
hands of
the plugin developer?

I think I'll try experimenting with pluginifying something in Flot, like you 
did with
the log patch, to understand this better.

Original comment by olau%iol...@gtempaccount.com on 22 Mar 2009 at 12:19

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think defining hooks and API semantics would be a better approach than I 
took.  My goal was to absolutely 
minimize the changes to the Flot code but allow for some extendability.  I took 
this approach to make it easy to 
maintain my custom additions to Flot and merge with new releases.

My approach has limitations that could be addressed with a proper plugin API.  
For example, extending the drawing 
methods or event callbacks is difficult because of the closures involved and 
when events are bound to objects.  For 
example, extending the log axes plugin so it will return the actual user data 
values on plick click/ hover events, and 
not the scaled values, is really tricky.

My approach is very simple, and does work well for modifying data, options, and 
things that happen prior to drawing 
and event binding.  A proper plug-in API would be much more powerful but 
undoubtedly involve more changes to 
the core.

Original comment by chris.le...@gmail.com on 22 Mar 2009 at 1:53

[GoogleCodeExporter]

I've recently committed the first steps of this. Now one can register plugins 
and
install (a few) hooks. To make this complete, more hooks need to be defined and 
we
possibly need to expose more of the internal state.

Original comment by olau%iol...@gtempaccount.com on 25 May 2009 at 11:45

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Thanks.  I'll check it out.

I've started working on a highly plugable plotting package.  It is open source, 
if
you are interested I can send a link to the web site.  I didn't want to post it
directly to the issue tracker or mailing list and seem like I'm spamming your 
project.

Flot has more features.  I needed some special capabilities that probably don't 
fit
in with Flot, though, so I began rolling my own.

Original comment by chris.le...@gmail.com on 2 Jun 2009 at 6:38

[GoogleCodeExporter]

OK. I think you're not the only one interested in tracking the progress of 
plugin
support, so I'll continue posting to this issue. :) Feel free to unstar 
yourself if
you don't want the spam.

I've added two extra hooks for interactive things and moved crosshair support 
to a
plugin. Next up is probably drawing series.

PS: I googled your project, it'll be interesting to see whether it works out. 
The
overall idea appears to me to be somewhat similar to what I'm arriving at, 
although
we're structuring it differently.

I couldn't help noticing that you got around the clipping problem with an extra
canvas, neat trick when IE doesn't play nice with clipping paths, maybe I 
should try
that, the clipping code is by far the most unreadable part of Flot. A quick test
seems to indicate that Firefox 3 and IE 6 is buggy with far away points, 
however, darn.

Original comment by olau%iol...@gtempaccount.com on 2 Jun 2009 at 6:15

[GoogleCodeExporter]

I am interested in following the progress on the issue.  By spamming, I meant I
didn't want to spam your site here with links and talk about my project.  But 
since
you mentioned...

Thanks for the tip about far away points on my jqPlot project  I'll check into 
that.

As far as canvases in jqPlot go, plugins are free to add their own canvases.  
For
example, the dragable plugin (dragging data points) uses its own canvas to avoid
expensive redrawing of a lot of plot elements.  The CanvasAxisTickRenderer 
plugin
renders tick labels on their own canvases so it can draw rotated text.  This is
probably a necessary feature when you don't know how external plugins will want 
to
draw on the plot.

Original comment by chris.le...@gmail.com on 2 Jun 2009 at 10:55

[GoogleCodeExporter]

The API is probably not complete yet, but it seems there is little point it 
keeping
the bug open now so I'll just close it. In any case, thanks for working on it!

Original comment by olau%iol...@gtempaccount.com on 27 Oct 2009 at 1:18

• Changed state: Fixed