Upgrade to Flot 0.6
Aaron Valade
I needed to use some of the recent functionality in the Flot jQuery
plugin which is version 0.6. The Flot lift-widget is currently at
0.4. So I upgraded it to use the new version and I've posted the
commit on github:
http://github.com/avalade/liftweb/commit/fa3d76fb72a7f74d13265e4039f034b4ada39492
Version 0.6 of Flot does make one breaking change which requires some
of the options which were previously described as a top level
attributes on the FlotOptions object to be pushed inside of a new
attribute called FlotSeriesOptions. I've made the appropriate changes
to the various example Flot charts which were included in the flotDemo
module.
Would it be possible to get this change upstream?
- Aaron
David Pollak
What do you think of the upgrade (given that you're the most Flot-ish Lift committer)?
Thanks,
David
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Aaron Valade
had sent this email in that I deleted the excanvas.pack.js file and
dropped in the excanvas.js that was included with the Flot 0.6
distribution but didn't rename it to be excanvas.pack.js and didn't
change the path in the Flot.scala file.
I can make an additional commit that fixes this, if it pleases the court. :-)
- A
Peter Robinett
something that I've been meaning to do. Just skimming over your
changes, everything looks good. As for not using the packed excanvas
file, that should be ok since Lift runs the YUI compressor by default
on all Javascript files (correct, David?). Of course, broken URLs need
to be fixed.
David, how do we go about merging these changes?
Peter
On Jan 29, 3:32 pm, Aaron Valade <a...@alum.mit.edu> wrote:
> There is one break that my commit made which I just realized after I
> had sent this email in that I deleted the excanvas.pack.js file and
> dropped in the excanvas.js that was included with the Flot 0.6
> distribution but didn't rename it to be excanvas.pack.js and didn't
> change the path in the Flot.scala file.
>
> I can make an additional commit that fixes this, if it pleases the court. :-)
>
> - A
>
> On Fri, Jan 29, 2010 at 6:15 PM, David Pollak
>
>
>
> <feeder.of.the.be...@gmail.com> wrote:
> > Peter,
>
> > What do you think of the upgrade (given that you're the most Flot-ish Lift
> > committer)?
>
> > Thanks,
>
> > David
>
> > On Fri, Jan 29, 2010 at 12:32 PM, Aaron Valade <a...@alum.mit.edu> wrote:
>
> >> Hello all,
> >> I needed to use some of the recent functionality in the Flot jQuery
> >> plugin which is version 0.6. The Flot lift-widget is currently at
> >> 0.4. So I upgraded it to use the new version and I've posted the
> >> commit on github:
>
> >>http://github.com/avalade/liftweb/commit/fa3d76fb72a7f74d13265e4039f0...
>
> >> Version 0.6 of Flot does make one breaking change which requires some
> >> of the options which were previously described as a top level
> >> attributes on the FlotOptions object to be pushed inside of a new
> >> attribute called FlotSeriesOptions. I've made the appropriate changes
> >> to the various example Flot charts which were included in the flotDemo
> >> module.
>
> >> Would it be possible to get this change upstream?
>
> >> - Aaron
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Lift" group.
> >> To post to this group, send email to lif...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> liftweb+u...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/liftweb?hl=en.
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
Indrajit Raychaudhuri
compressor at build time is what lift-webkit does at the moment.
How about injecting the excanvas JS conditionally (via ieMode)? This is
mostly cosmetic though.
Cheers, Indrajit
David Pollak
Please keep in mind the Lift IP policy. We don't pull from other repositories nor do we accept patches. We'll have to do the Flot 0.6 ourselves.
Thanks,
David
Aaron Valade
Sent from my iPhone
Timothy Perrett
Sent from my iPhone
Peter Robinett
now).
Peter
On Jan 31, 3:20 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> It seems like peter will take ownership of this and make it happen
> ASAP so a patch / diff should not be needed.
>
> Peter, please confirm when you will roll this in a branch and put it
> on review board?
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 31 Jan 2010, at 22:48, Aaron Valade <aval...@gmail.com> wrote:
>
>
>
> > I'm more than happy to submit the patch under the Lift IP policy,
> > but I understand if you don't feel comfortable with that. And I can
> > submit it anyway that works for you. I'm just looking to help give
> > back to everyone that's helped me out. Albeit in a very, very small
> > way.
>
> > Sent from my iPhone
>
> > On Jan 31, 2010, at 5:43 PM, David Pollak <feeder.of.the.be...@gmail.com
Aaron Valade
One of the other things that changed between Flot 0.4 and 0.6 is that
a plugin structure was introduced and some functionality was pushed
out of the core and into a plugin, specifically the selection
functionality which can be used for zooming and other interactions
with the charted data. I hate to tack on requests for more work, but
if you get a chance, I'd appreciate if you could add functionality to
the Lift Flot Widget to allow use of these plugins. I'm in the process
of making some small changes with the Flot Widget to support these
plugins in my local fork of Lift and would be happy to share what I've
done, if that's allowed. Otherwise, I'd be very eager to provide
additional testing of any capabilities that you make available or any
other help that I can provide within the guidelines of the Lift
project.
Thanks,
- A
Peter Robinett
please open a ticket on GitHub (http://github.com/dpp/liftweb/issues).
Peter
Aaron Valade
Peter Robinett
I've pushed the simplest update possible to my branch here:
http://github.com/dpp/liftweb/tree/pr1001_issue_322. I will make the
series options change if there are no significant dissenting voices in
the thread I created[1]. In the meantime, do. The flotDemo app seems
to work without any changes.
What do you think?
Peter
[1]: http://groups.google.com/group/liftweb/t/ba7e0f76042ff562
Aaron Valade
One little nit is, could we add the "hoverable" option to
FlotGridOptions? That's a new feature which was added to Flot which
shouldn't break backwards compatibility.
Any thoughts about integrating plugins as the zooming and FlotOverview
class don't work without the selecting plugin.
- A
Peter Robinett
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?
Peter
> ...
>
> read more »
Aaron Valade
The naive way I've approached this problem so far was by creating:
trait FlotPlugin {
val pluginFile: String
}
and then creating objects that extended that with the name of the plugin file:
object FlotSelection extends FlotPlugin {
val pluginFile = "jquery.flot.selection.js"
}
Then I added a new var and a new init method inside the Flot object
var plugins: List[FlotPlugin] = Nil
def init(fp: FlotPlugin*) {
plugins = fp.toList
init()
plugins.foreach{ p =>
ResourceServer.allow({
case "flot" :: p.pluginFile :: Nil => true
})
}
}
And I also added a for loop into the renderHead method to yield a
script include for each plugin that was in the plugins List of the
Flot object. That way, I could at least choose in my Boot.scala which
plugins I wanted to initialize in my project by calling
Flot.init(FlotSelection).
Ideally, it would be cool if you would define a FlotCapability as
needing a particular FlotPlugin and then use some method inside of
Flot.init to lookup all the FlotCapabilities that you've declared in
your project and then initialize the plugins based on that list. I'm
not sure if there's a good way to do that outside of using reflection
though as I'm not too familiar with the Lift initialization process.
- Aaron
Jeppe Nejsum Madsen
> 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
Peter Robinett
merging means that you just include the necessary script tag in your
snippet right before the code that will call it. However, this isn't
always so easy (for example, when doing AJAX responses). This is of
course after the ResourceServer has allowed the appropriate file.
My inclination is to do something quite similar to what Aaron
describes. Looking towards a general solution, maybe there could be a
net.liftweb.http.js.JsScript class that can be used to include the
appropriate Javascript files via ResourceServer.allow. Would that make
sense?
Peter