Provide parseJson plugin (and nothing more) #73

merged 2 commits into from Apr 3, 2013


None yet

3 participants


A fixed minimal addition of two files for adding a parseJSON plugin.

Gexf plugin is not compatible with IE and also creates repeated work by parse xml on every client. Optionally, creators should be able to parse the xml once, store the results in json, and load this

The modifications provide this functionality. The plugin parseJson allows loading a json file of node and edge info. The python script (gexf2json) creates a json file from a gexf file.

The json file loads about .55-.65 seconds faster on localhost and in general has a smaller file size. It is compatible with major browsers (including IE). The json relies on jQuery, which must also be loaded by the user. Finally, the modifications allow a callback function to be passed to parseGexf or parseJson to be executed after data is loaded.

The json structure exactly mirrors the results from parseGexf for compatibility. I would really like, however, to see a dictionary instead of a list for attributes in the future.


This fixes issues #16 and #45


The json structure exactly mirrors the results from parseGexf for compatibility.

It does, but your pull request doesn't actually include client-side code to load most of that data. Until it does, you might as well remove the position/size/colour attributes and make the JSON prettier (and smaller).

I'm generally not particularly thrilled with the idea of completely removing sigma.parseGexf.js. Unlike GEXF, this JSON isn't a documented format, and there will always be some sites where a completely client-side display solution for GEXF is handy.

I think the Python script should probably go in a contrib/ directory, or else a separate project referenced in (which would mean you could also include references to the Java implementation). It's not JavaScript and shouldn't be deployed to an assets folder or be scanned by a minifier.

Sorry for the negativity... sigma.parseGexf.js is not pretty (and neither is GEXF), but for the moment it really does incorporate more (if not better) functionality for those browsers that support it.

👍 for including sigma.parseJson.js though. Good to have another file format option.


Sigma does load the position/size/colour attributes from the JSON. So, all of these get used. What might not get used is all of the data parsed into the "attributes" array that gets added to the node. It is hard, however, to decide what to remove from this because the user may want these values to display or use in their own JS. Like sigmas.parseGexf.js everything in the gexf is parsed and made available. Exactly the same fields used in sigma.parseGexf.js are used in sigma.parseJson.js

I agree that sigma.parseGexf.js should not be removed. I think it provides some handy functionality; however, there is definitely inelegance, inefficiency, and incompatibilities in downloading the larger XML file and parsing it repeatedly on every client machine. The JSON format expected by sigma.parseJson.js is exactly what sigma.parseGexf.js produces itself. It would even be possible to have parseGexf return the arrays of nodes and edges and feed these directly as input into a local parseJson function (although I have no idea why one would do this).

Good points on the contrib/ / separate project ideas and the I think these make sense. I'll let @jacomyal decide how he'd like to pull these in.

computermacgyver added some commits Mar 10, 2013
@computermacgyver computermacgyver Merge pull request #7 from yaph/devel
ie parseGexf fix, parseJson use unique edgeId, python fix for attributes not in dict. Thanks, yaph.
@computermacgyver computermacgyver drop id, label from edges; check for edge attributes not in dict; sto…
…re weight to size parameter
@jacomyal jacomyal merged commit 82702e5 into jacomyal:master Apr 3, 2013
@mattcg mattcg referenced this pull request Apr 8, 2013

Support viz:* in GEXF in IE #90

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment