JSON, La rivoluzione WEB è alle porte
Posted by Santarelli Luca | Filed under Programmazione Web
-> Nel 2008 la maggior parte dei browsers includeranno il Parse di JSON
-> Inoltre un imminente standard permetterà ad un browser richieste sicure di JSON da terzi Domini.
Quando entrambe le tecnologie saranno implementate, entreremo nel mondo del web 3.0 dove ogni browser può richiedere qualunque dato JSON pubblicato dovunque nel mondo e gestirlo internamente senza la necessità di coinvolgere server.
XML quando fu introdotto ha mosso le acque, ma JSON, quando sarà completamente supportato dai browser, farà uno tsunami: preparatevi per il giorno della nuova rivoluzione!Cosi si può leggere sul sito ufficiale json, ma hanno torto? vediamo gli apsetti fondamentali di JSON, e di cosa lo fanno vincente.
JSON(JavaScript Object Notation) è basato sugli standards ECMA-262 terza edizione e sulla programmazione in Javascript, linguaggio basato su questo stesso standard.
Questo formato permette a tecnologie differenti di scambiare informazioni e si rivela anche un buon metodo per interagire con chiamate asincrone, poichè permette di inviare diversi tipi di dati sotto forma di stringhe ben interpretabili dalla quasi totalità dei linguaggi server.
I tipi di dato che possiamo usare con JSON per lo scambio di informazioni sono due:
- array con soli indici numerici
- oggetti
In JSON tutto è rappresentato come stringhe, le quali sebbene possano apparentemente sembrare il tipo di dato più semplice da convertire, sono le più complesse a causa del set di caratteri “unicode”, supportato da JavaScript, ma non sempre presente o supportato allo stesso modo da altri linguaggi.
Ovviamente il fatto di essere tutto interpretato come stringa ci porta ad un problema abbastanza serio da affrontare, ovvero quello dei caratteri speciali, come la tabulazione(\t),(\n), i caratteri di escape dell’html, ecc, per questo ci viene in aiuto una libreria
scritta da uno dei massimi rappresenti JSON, che ci fa il parser delle stringhe manipolate con JSON.
Ricreare una variabile da una stringa formattata correttamente è l’operazione più semplice e veloce che ci possa essere, a prescindere dalla complessità o lunghezza del dato in ingresso e sempre rimanendo in ambito JavaScript. Questo grazie alla funzione eval(), in grado di valutare quasi in tempo reale una stringa come se fosse codice scritto direttamente dallo sviluppatore.
Un array mediamente complesso, da migliaia di elementi innestati di vario tipo, può essere quindi tranquillamente riassegnato in una manciata di decimi di secondo. Quindi l’assegnazione manuale e quella in JSON sono praticamente uguali.
Quello che invece rallenta in modo consistente lo scambio dati è proprio la conversione in stringa a partire dal dati originali
, è sempre corretto tenere a mente questo collo di bottiglia in conversione.
Ad esempio l’invio in JSON dell’intero contenuto di una tabella di un database potrebbe essere fattibile, sarebbe consigliabile però spezzettare le informazioni inviando 100 record per volta o anche meno a seconda dei contenuti, per non creare rallentamenti all’utente ed al server, visti dei calcoli richiesti per queste conversioni.
Il prototype di stringa dedicata, assegnato nel file json.js citato prima, che ha il compito di verificare il corretto formato e comportamento della stringa in fase di riassegnazione, potrebbe rallentare ulteriormente la trasmissione. È apparentemente inutile ma tecnicamente importante sfruttare questo metodo al posto del solo eval, infatti eval valuta ogni tipo di codice col rischio di elaborare anche del codice “maligno” o non desiderato.
Dal mio punto di vista mi sembra un appunto molto importante, ma in fin dei conti non è un collo di bottiglia,quando AJAX effettua una richiesta asincrona non si limita a restituire il solo testo ma verifica che tale pagina sia di tipo XML e senza errori per poi riassegnare il tutto alla variabile responseXML, restituita come oggetto o documento nativo di tipo XML. Quello che deve fare JavaScript a questo punto è estrapolare con metodi o funzioni più o meno complesse i dati, solitamente al fine di rappresentarli nuovamente come oggetti, liste di informazioni o variabili comunque analoghe.
Con JSON tutto questo non avviene, sia perchè una pagina adibita ad uno scambio dati di questo tipo non mostrerà le intestazioni corrette per un foglio XML, evitando quindi al motore interno al client di riconvertire il contenuto in documento, sia perchè il parsing delle informazioni avverrà per intero con una sola chiamata alla prototype di stringhe parseJSON.
Inutile esporre quanto tempo si possa risparmiare per sviluppare interazioni avanzate come altrettanto superfluo dire che gli stessi client potranno godere di calcoli molto meno pesanti e di un utilizzo di banda ridotta.
Che dire del XML, non è possibile mettere in discussione l’universalità o il successo dell’XML, tanto meno le sue potenzialità. Sono rappresentabili gerarchie semplici o estremamente complesse con la possibilità di ricostruire oggetti e variabili dalla lettura di attributi presenti nei nodi.
Esiste però un neo connaturato a XML: il numero elevato di caratteri necessari a rappresentare le informazioni. Se è vero che per un server leggere un file da 10Kb o da 1Mb è pressapoco equivalente, non lo è altrettanto per un client.
Questa caratteristica è tanto più evidente quanto più piccola è l’informazione da trasportare. Si arriva al paradosso di avere più caratteri per la descrizione del documenti, che per i dati veri e propri. Un utilizzo massiccio di attributi potrebbe aiutare a rosicchiare qualche carattere ma oltre a perdere in linearità e leggibilità non si riuscirebbe comunque a guadagnare troppo spazio. Il resto commentatelo voi.
No related posts.
Articoli correlati elaborati dal plugin Yet Another Related Posts.
Tags: Ajax/Json
Scritto da Santarelli Luca domenica, 8th febbraio , 2009 18:43 Letture:« Guida all’uso dei template con Freemarker e java servlets | Richieste XMLHttpRequest con JSON e PHP »

blogflux