JSON Export/Import - is this wanted?

[Andrew Mee]

I have done some work on a JSON export/import instead of the XML one.

I would be happy to send a patch - however it would be sizeable as I would need to change the mutation handling on blocks from XML to JSON.

Is this something the community would like?

Regards

Andrew

[Chris Jackson]

Personally, I also think that json is more useful and also changed my personal repo on Github over to use json instead of XML (since it wasn’t so easy to support both due to the mutators). I would certainly vote for this to be a main part of the build.

Chris

[Andrew]

What I did is I wrote the JSON parser to use a new dataToMutation and mutationToData in each block - however I also allow a fall-back to use the existing domToMutation/mutationToDom which saves the mutation (in XML) as a string.

That way it would allow for gradual updates to blocks.

The other changes is the ability to use my own variable names for the import/export so in my case 'title' becomes 'sTitle' - although not sure how to make this an option as yet.

Any other suggestion or features people would like?

I guess I'm looking for feedback from the project owners as well before I start.

On 9 September 2014 22:00, Chris Jackson <ch...@cd-jackson.com> wrote:

Personally, I also think that json is more useful and also changed my personal repo on Github over to use json instead of XML (since it wasn't so easy to support both due to the mutators).  I would certainly vote for this to be a main part of the build.

Chris

--
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/UqrKC5RNdH8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Regards

Andrew

[Eric Miller]

I also would prefer working with JSON over working with XML. I will vote for the change, but I'm curious to hear what led to the original choice of XML. Perhaps support for archaic browsers like IE7?

[Andrew]

So here is a part one of JSON export/import for Blockly - you will need to run the build script after this patch.

I have NOT touched mutations on blocks at this stage - this still records mutations as XML strings - I will add these if this is ok.

Please review and let me know what fails :)

Andrew

--

You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/UqrKC5RNdH8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Regards

Andrew

[Andrew]

Sorry I should have also mention that I integrated this into the code app so you can play and compare.

Andrew

--
Regards

Andrew

[Mark Friedman]

I can provide a little insight into the original choice, as I was around at the time and reviewed the original code from Neil.  Neil may weigh in as well, if I end up misrepresenting what happened ;-)

 I believe that the general idea was that it was fairly natural to think about their being a DOM corresponding to the Blocks, in the same way as there is a DOM for the HTML contents of a page.  From that it's natural to use the built in XMLSerializer and DOMParser classes for export and import.  I don't believe that there (or are) built in classes for serializing and parsing DOMs to/from JSON.

I'm curious why you folks are interested in JSON import/export, given that the XML version already exists?  I'm not a big fan of XML, but why change now?

-Mark

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.

[Andrew]

I only started using Blockly in the last 9 months and it was one of the first things I did was write this parser.

I take the Blockly structure in JSON and then parse that in PHP to process what our clients want on the back end. It is *much* easier to turn JSON into a PHP multi-dimensional array and process this than trying to use XML.

XML I find as a structure pretty horrible to work with in general as it doesn't match normal PHP array or JavaScript Object, and now I avoid XML as much as possible :)

- just my 2cents

Andrew

--
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/UqrKC5RNdH8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Regards

Andrew

[Marcus F]

This may be old, but I just wanted to put my 2 cents in.

XML is no longer the standard for working with data, JSON is the new king, and is pretty much the expected format when pushing/pulling data online.

XML is horrible to work with, JSON is nowhere near as bad.

It's easier to turn JSON into other things, than it is with XML.

(ps blockly is awesome)

[Marcus F]

I've applied the patch, but how would I.. use it?

[Marcus F]

After a little tinkering, I got it to work (At least with exporting, haven't tried importing yet.)

[Marlon Smith]

would be nice if this is supported officially.

--

You received this message because you are subscribed to the Google Groups "Blockly" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.

[David ten Have]

I'd like to +1 the request for official support.

While I get the structural relationship that lead to XML, from an interop point of view JSON is much more preferable.

[phil cleaver]

Hey all,

I was wondering if there was any progress on this.  I ask because looking at bug report 19  - https://github.com/google/blockly/issues/19 

it says 

While trying to update the JSON import/export I was trying to build the demos/code application. with the latest release the instructions for building the apps using soy are broken.

Does this mean that there is a way of doing JSON import / export, is there any documentation anywhere?

Thanks

Phil

[Andrew]

The pull request I put in for json export import became out of date and I tried to update and my git skills failed me :( and it broke. I will be putting up a new pull request soon.

That being said I have had no feedback from the devs regarding this patch and I'm unsure if it is ok or not. If I have approached it the right way? or if it has a chance of being merged - and I'm kinda of groping around in the dark about what will happen to it.

I also have a patch on the way for multi-line text as well - but again I'm not sure what is going to be accepted or not. 

Thanks

Andrew

[phil cleaver]

Andrew,

Thanks for the reply, they both sound awesome, I hope they get accepted.

Phil

[Rodrigo Ipince]

Hi all,

Reviving an old thread.

Did JSON import/export ever made it into the project?

I was only able to find https://github.com/google/blockly/pull/20, which isn't merged. But I also saw https://github.com/google/blockly/issues/643 , which hints that there may be something in the develop branch. Can someone update on the status?

Thanks!

-Rodrigo

[Neil Fraser]

The Blockly, Scratch, and App Inventor teams had a big conversation about this in February.  Our conclusion was that having a single save-file format opens the door to interoperability between projects.  Imagine an OzoBot program loaded into Scratch, or a Scratch program loaded into App Inventor, or an App Inventor program loaded into Open Roberta.

A good analogy is railroads.  At one time every country or state had small regional railroads.  They each picked a track gauge that were ideal to each of their particular cases.  The fact that they were different to each other didn't matter -- until decades later when they grew to a point where they started meeting.  By that point standardization on a single track gauge was terribly difficult.

More and more Blockly applications are being created, and their scopes are growing.  Soon we are going to see separately developed Blockly applications talking with each other.  Let's not compound the difficulty of this by introducing multiple save-file formats.

Obligatory XKCD:  https://xkcd.com/927/

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Neil Fraser
https://neil.fraser.name

[Andrew]

However this work wasn't about a different format per se, it was the same format/structure in JSON instead of XML to make it easier for other programs to parse the data. We are using Blockly to generate an AST like structure for PHP to parse server side and using the XML was incredibly inefficient to work with hence why this was created. Even using JavaScript it much easier to work with JSON than XML :)

I guess if you are using Blockly XML output only for Blockly the arguments works not to change it.

To unsubscribe from this group and all its topics, send an email to blockly+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards

Andrew