About Flotr's modularity

[GoogleCodeExporter]

Bas and me think that Flotr should be splitted into modules. I've thought
about it a little and think it should be splitted like that : 
* core - Flotr
* graph - Flotr.Graph
* color - Flotr.Color
* events - Flotr.Events or Behaviour - Mouse events, map areas...
* date - Flotr.Date
* text - Canvas.Text
* export - Flotr.Export
*    image - Flotr.Export.Image
*    csv - Flotr.Export.Data
* tabulations - Flotr.Tabs
* spreadsheet - Flotr.Spreadsheet
* portability - Canvas.Portability?
*    ie (excanvas)
*    others ?

Original issue reported on code.google.com by fabien.menager on 28 Nov 2008 at 9:58

[GoogleCodeExporter]

Do you need help on this? I can give a hand.

Original comment by cesar.iz...@gmail.com on 30 Dec 2008 at 5:54

[GoogleCodeExporter]

I've been playing around with separating the different classes in different 
files and
having a system to load the modules on demand. Attached is a patch that 
implements
this. This is what it does:

* Adds a include.js, part of the modularjs project 
(http://modularjs.googlecode.com)
that I just created
* Renames prototype-1.6.0.2.js to prototype.js (the build system doesn't 
support yet
version numbers in module names, it treats them as packages)
* Fixes a invalid variable name "char" in canvastext.js
* Renames flotr.js to Flotr.js to standarize on CamelCase names for packages
* Creates a flotr/prototype/Flotr directory with some modules like Core.js, 
Graph.js,
Date.js, Color.js, and some other empty modules for now.
* Changes the head of examples/prototype/*.html to use import.js and imports 
only the
modules needed (currently Flotr and Flotr.Graphics that in turn depend on 
Flotr.Core
and Flotr.Color)

The examples work unmodified (besides the change in the script tag on the head).

I'm also attaching a built compressed version of all modules that currently 
takes
about 148kb including all libraries vs. 283kb that sumed all the old files. 
Further
optimization could be achieved by not including in this build the files needed 
only
by IE and having them load dynamically as like it works without building.

To make a build version you need python and run this on a terminal:

sudo easy_install distutils
sudo easy_install modularjs

Then go to the flotr/prototype folder and run

modularjs init
modularjs build Flotr Flotr.Graph

Two files should be present Flotr.build.js and Flotr.build.compressed.js

Any of those files could be used in place of include.js in the script tag in 
the head
of the examples.

Original comment by cesar.iz...@gmail.com on 5 Jan 2009 at 10:08

Attachments:

• modular.patch
• Flotr.build.compressed.js
• Flotr.build.js

[GoogleCodeExporter]

Hello Cesar and sorry for the late reply, I forgot it and didn't read that much 
the
bug tracker.
All of this seems to be good, there are only a few things that make me meditate:
 * In the modularJS project, you use Ajax instead of writing a <script> tag as every
lib that does that uses, is there any reason for this ?
 * I don't really like the CamelCas for the file names, I prefer using underscores
and avoid any strange character, like Java package system does (I think so).
 * Your patch is for an old version of Flotr (before r78) and I didn't apply it, as
lots of changes were made. But I looked at it, and the concepts seems to be 
good.
 * IMO, the term "include" should be "import" or "require" as they are requirements.

After all this, I really like the possibility to have a build system and an 
import
system to let two choices that will led to the same final result : a custom 
Flotr.
For the moment, I'm working on other professional projects and won't be 
available for
a few days. But when I'll be free, the first thing I'll work on will be 
modularity.
Waiting for this moment, we'll be talking on the Flotr Google Group :)

Cheers 
Fabien

Original comment by fabien.menager on 13 Jan 2009 at 9:22

[GoogleCodeExporter]

Thanks a lot for your comments Fabien. I'd like to make it a little bit more 
clear
about my choices:

> * In the modularJS project, you use Ajax instead of writing a <script> tag as 
every
>lib that does that uses, is there any reason for this ?

Actually there are some frameworks that use the ajax approach. There is a basic
difference between both approaches, but I like the ajax approch more because if 
you
use <script> tags then you cannot do something like this:

include("SomeDependency")
SomeDependency.doSomething()

This happens because when you write to the DOM, the tag that you just appended 
is
going to be evaluated just after the javascript that you are running that 
moment.
You'll have to wait for the script to be loaded and then run some code that 
depends
on it. On the other hand the ajax approch (using synchronous ajax) loads the 
file
inmediately. I learned this from the way Dojo works. If you use <script> tags 
then
you need to be very sure to load first all requirements before you load your 
scripts
that depend on those requirements. There's a comparisson of some of this 
methods in
the following URL:

http://www.web2coder.com/website-design/dynamically-loading-external-javascript-
file-3

> * I don't really like the CamelCas for the file names, I prefer using 
underscores
>and avoid any strange character, like Java package system does (I think so).

For this I was just using the same nomenclature that the ticket had originally. 
I
like lowercase for packages too.

> * Your patch is for an old version of Flotr (before r78) and I didn't apply 
it, as
>lots of changes were made. But I looked at it, and the concepts seems to be 
good.

I'll redo the patch with the observations here applying it to the latets svn.

> * IMO, the term "include" should be "import" or "require" as they are 
requirements.

I had a hard time deciding the name myself. I guess some programming languages 
use
include and some import and then some others require.  "include" sounds more 
like:
execute the code on that file right here like if the code was copied and pasted.
"import" sounds more like: process this file and load the modules you find in 
there.
I didn't think about "require", it sounds much better. I don't have an strong 
opinion
on this so changing that function name is ok for me.

>After all this, I really like the possibility to have a build system and an 
import
>system to let two choices that will led to the same final result : a custom 
Flotr.
>For the moment, I'm working on other professional projects and won't be 
available for
>a few days. But when I'll be free, the first thing I'll work on will be 
modularity.
>Waiting for this moment, we'll be talking on the Flotr Google Group :)

I guess it makes it easier for everyone to develop and extend Flotr. There are 
some
ideas I've been thinking of about modularity but I'll bring them to discussion 
some
time later. Thanks for your time, it's really appreciated.

César

Original comment by cesar.iz...@gmail.com on 13 Jan 2009 at 10:07

[GoogleCodeExporter]

Ok, you've convinced me about the loading method :)
We'll surely use "require" and lower case files, with of course CamelCase 
Classes.

I do thank you for the time and the effort you spend for this project ! I really
appreciate this, as Bas does, probably.
I really hope Flotr will be the future reference for dynamic plotting, it only 
need
some more "buzz" :)

Original comment by fabien.menager on 13 Jan 2009 at 10:43

• Changed state: Accepted

[GoogleCodeExporter]

I began implementing the modularity in Flotr : 
Every graph type is composed by :
 - default options as an object
 - a draw function
 - other functions, used by the draw function
 - extendXRange function to extend the axis (it was extendXRangeIfNeedeByBar before)
 - extendYRange function to extend the axis (it was extendYRangeIfNeedeByBar before)

I added a plugin feature too, every plugin is composed by :
 - a list of callbacks, with the callback event as key, and the function as value
 - functions used by the callbacks

Original comment by fabien.menager on 20 Jul 2009 at 5:06

• Changed state: Started

[GoogleCodeExporter]

Is there anything that remains to be done, or can this ticket be closed?

Original comment by peter....@solide-ict.nl on 20 Jul 2010 at 3:24