Peter Robinett <[email protected]> writes: > Hi Aaron, > > I just added hoverable to my branch. Please let me know if you have > any issues with it. > > As for plugins, I think it might take a little thinking to get right. > Looking at the Flot plugin documentation > (http://flot.googlecode.com/svn/trunk/PLUGINS.txt), a plugin registers itself > by calling > $.plot.plugins.push(pluginDefinitionObject). I think we could have a > generic plugin trait and make individual instances for each specific > plugin which would implement the minimum possible, which may simply be > including the plugin javascript file on the page. > > However, including the plugin Javascript files could be tricky. > Flot.init in boot.scala could be aggressive about including as many > plugin files as possible, but that's not a particularly elegant way. > However, including them elsewhere, for example as part of the > Flot.render, would make uses like calling Flot.render in a CometActor > tricky. > > Finally, I notice that plugins are allowed to add their own options to > the new series option object we've been discussing. Because by their > nature we can't anticipate all options, it may make sense that the > series object should be some sort of Map. > > What do people think?
I've also been thinking about this. I'm using jqPlot instead of Flot for various reasons and there the same issues arise. Also, several other jqQuery plugins are extendable with some sort of plugin mechanism and in much the same way. So maybe some of this could be made generic in some way? /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
