modisposition

I keep seeing developers complaining about different things with JSON protocol and don't get me wrong, I've been the first one trying to implement any sort of alternative starting from JSOMON and many others ... OK? Well, after so many years of client/server development is not that I've given up on thinking " something could be better or different ", is just that I have learned on my skin all reasons JSON is damn good as it is, and here just a few of these reasons. Reliable Serialization ? No , 'cause YAGNI . There are few serialization processes I know that kinda work as expected and since ever, PHP serialize is a good example. Recursion is not a problem, is part of the serialization process to solve it, as well as classes together with protected and private properties. You can save almost any object within its state, even if this object won't be, as reference, the same you serialized .. and I would say: of course ! There are also two handy methods, _...

I believe this is a common problem, and we had a similar one today while debugging. JSON methods do not support recursion ... which is the only thing I am really missing back to PHP serialize days. Recursion Is Bad Well, I would say cyclic references are never that good but sometimes these may happen and, specially while testing and debugging, it's more than useful to understand what happened there. If you have cyclic/cross references in your code I suggest you to use approaches which aim is to avoid these kind of direct links. Harmony Collections , specially Map and WeakMap, are indeed good helpers to reference indirectly objects without creating, hopefully, first level links and/or recursions. How To Serialize Anyway JSON.stringify() accepts a second argument called replacer . I won't explain more than MDN about its potentials, but it can be really handy to avoid recursions. A simple way to do it is indeed to store in a stack already parsed objects, included the object itse...

Another active exchange with @getify about JSON comments and here my take because tweets are cool but sometimes is hard to tell everything you think in 140 bytes ... Kyle Facts JSON is used on daily basis for billion of things and configuration files are one, surely common, way to use JSON ( just think about npm packages for node.js ). His frustration about the fact JSON does not allow comments is comprehensible, and he even created an online petition about allowing comments in JSON specs ... but are comments really what we need? Just A Side Effect JSON is extremely attractive as standard, first of all because it's available and widely adopted by basically any programming language in this world, even those that never had to deal with a single JavaScript interlocutor, secondly because it's both simple to parse, and easy to read for humans. After all, what can be so wrong about comments inside such common serialization standard? Aren't comments just as easy to parse as whi...

The freaking fast and bandwidth saver JSONH Project has finally a new schema argument added at the end of every method in order to make nested Homogeneous Collections automatically " packable ", here an example: var // nested objects b property // have same homogeneous collections // in properties c and d schema = ["b.c", "b.d"], // test case test = [ { // homogeneous collections in c and d b: { c: [ {a: 1}, {a: 2} ], d: [ {a: 3}, {a: 4} ] } }, { a: 1, // same h...

I have already described JSONH and now I also have the proof that it's as safe as native JSON is but on average 2X faster than native JSON operations with both small (10 objects), medium (100 objects), and massive (5000 objects and not a real world case, just a stress test to see how much JSONH scales) homogenous collections. Wherever it's not faster it's just " as fast " but the best part is that it seems to be always faster on slower machines ( mobile ). Moreover, the 5000 objects stress example shows that JSONH.stringify() produces a string with 54% of original JSON.stringify() size so here the summary: JSONH is faster on both compression and decompression plus it produces smaller output yeah but ... what About Hybrid Objects To start with, if you don't recognize/understand what is an homogenous collection and ask me: " what about nested objects? ", all I can do is to point you out that Peter Michaux explained this years before me. Have a ...

Update created github repository with (currently) JavaScript, PHP5 and Python versions. Update after quick chat on twitter with @devongovett who pointed out there is a similar standard called JSONDB I have created a JSONH(Flat) version . It looks slightly faster on mobile so I may opt for this one rather than Array of keys at index 0. The whole array is flat and it changes from [{a:"A"},{a:"B"}] to [1,"a","A","B"] where the empty collection would be [0] rather than [[]] . Also more details here on how to JSONH Hybrid JS Objects . A while ago I proposed a homogeneous collections optimizer nick named JSON.hpack . What I wasn't expecting is that actually different projects and developers adopted this technique to shrink down JSON size. Basic Advantage Of JSON.hpack Gzip and deflate work really good with repeated chunks of strings and this is why homogeneous collections have really good compression ratio there. However, gzip...

I have just uploaded a truly simple, still robust, function able to do generic JSONP without pretending too much magic. The concept is simple, we pass the url, including the parameter name used to communicate the callback name, and a callback as second argument ... that's it, 202 216 bytes minified and gzipped ( many thanks @jdalton for the catch ) Here an example: <!-- the generic HTML page --> <script src="JSONP.js"></script> <script> this.onload = function () { var many = 0; JSONP("test.php?callback", function (a, b, c) { this.document.body.innerHTML += [ a, b, ++many, c ].join(" ") + "<br />"; }); JSONP("test.php?callback", function (a, b, c) { this.document.body.innerHTML += [ a, b, ++many, c ].join(" ") + "<br />"; }); }; </script> And here the testable demo result that should work with every bloody damned browser. What's on the server? No...

The JSON protocol is a de facto standard used in many different environments to transport objects, included arrays and Dates plus primitives such: strings, numbers, and booleans ... so far, so good! Since this protocol is widely adopted but it has not the power that a well known function as is the PHP serialize one has, we are often forced to remember how data has been stored, what does this data represent, and eventually convert data back if we are dealing with instances rather than native hashes. If we consider the ExtJS library architecture, we can basically have a snapshot of whatever component simply storing its configuration object. The type will eventually tell us how to retrieve a copy of the original component back and without effort at all. Since JSON is the preferred protocol to store data in WebStorages, databases, files, etc etc, and since we can save basically only hashes, loosing every other property, I have decided to try this experiment able to bring some magic in the...

I know yesterday post supposed to be the last 'till the the end of the month but I could not resits. Dustin Diaz twitted anyone trying to parse our wonky rails dates in JS. do this: var date = Date.parse(str.replace(/( \+)/, ' UTC$1')); seems to fix it. Again, I could not resist to create a toUTCString based function to create JSON strings and to parse them back. This is the result and apparently is both the fastest implementation I know and cross browser (Chrome, Firefox, Inernet Explorer, Safari). This is a quick post so if you find some problem please let me know, thanks. (function(){ // WebReflection Fast Date.prototype.toJSON and Date.fromJSON Suggestion var rd = /^.{5}(\d{1,2}).(.{3}).(.{4}).(.{2}).(.{2}).(.{2}).+$/, rs = /^(.{4}).(.{2}).(.{2}).(.{2}).(.{2}).(.{2}).+$/, d = new Date, f = /(GMT|UTC)$/.exec(d.toUTCString())[1], // cheers gazheyes m = {}, i = 0, s = "" ; d.setUTCDate(1); while(i < 12){ d.setUTCMonth(i)...

Let me try again, this time with an official project page and a nearly complete wiki page . JSON.hpack, the Fat-Free Alternative to JSON JSON.hpack is a lossless, cross language, performances focused, data set compressor. It is able to reduce up to 70% number of characters used to represent a generic homogeneous collection. To understand how to use JSON via JavaScript, PHP, or C# (Python coming soon and hopefully other languages as well), please have a look into the wiki page or if you want, try out the demo page ! I am waiting for comments :-)

I found this dojo related post extremely interesting and I instantly though in our application we have similar JSON structure which is effectively redundant and, for thousands of database rows, it slows down visualization responsiveness (not that much in intranet, enough via internet). JSON.hpack I am developing on spare time an "all web languages" homogeneous collection packer in order to speed up client/server interaction specially for database results where the column name could be considered as a key and each field in the same column as a row. So far I created a JavaScript version which seems to work perfectly and results are quite impressive. For example, the total size of the 5000 items used in that dojo article switched from 37.23Kb to 26.27Kb , gzipped size, while number of characters to send / retrieve are 776133 against 99575 . As example, the host where I put the initial test does not allow more than 50Kb as uploaded data, this means that without JSON.hpack is not...

For those that do not know JsonML , this is a little summary. JsonML aim is to use JSON to transport layouts, instead of simple data. Unfortunately, for this purpose the size of the code could be even bigger than regular layout, considering that with a good usage of classes, internal styles, as attributes, are often superfluous. At the same time, there are still several problems with DOM, for its not standard nature, thanks to those browsers that do not respect W3 or generic predefined guidelines. For these reasons, and probably others, JsonML has not been widely adopted, as is for his daddy JSON . An alternative purpose, based on both same concept and grammar A daily common task in web development, is menu, files and directories, or trees creation, that allow us, as users, to organize data in a better, friendly, and easy to manage, way. Removing some intermediate step, and thinking about standard data presentation, with useful information and nothing else, it is possible to use the...

This is the second time I open this post because I didn't do a good debug but my solution, a sort of personal brainstorming, was good enough to open one more time this post after few changes :) This is my proposal: (function(m){function $(c,t){t=c[m];delete c[m];try{eval(""+c)}catch(e){c[m]=t;return 1}};return $(Array)&&$(Object)})("toString") exactly 130 byte to solve (I suppose) Array and Object modified constructor problems. (function(m){function $(c,t){t=c[m];delete c[m];try{new(function(){}).constructor("",""+c)}catch(e){c[m]=t;return 1}};return $(Array)&&$(Object)})("toString") exactly 158 byte to solve (I suppose) Array and Object modified constructor problems. Let me explain this function concept. Step 1 - There's no way to know if a constructor is native This is the first problem, we can't believe on a generic object constructor for, at least, these two reason: a constructor, as I wrote on MDC too , ...