Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

JSON : regardons en détail de quoi il s'agit

JSON veut dire JavaScript Object Notation, j'en avais parlé il y a quelques temps (javascript : un langage incompris - Les namespaces / JSON) et j'avais comparé JSON a une sorte de XML pour JavaScript. En effet si vous voulez transiter un objet Image qui contient de nombreuses propriétés, la représentation JSON vous permet d'avoir ceci :

var image ={ "Width": 800, "Height": 600, "Title": "View from 15th Floor", "Thumbnail": { "Url": "http://www.example.com/image/481989943", "Height": 125, "Width": "100" }, "IDs": [116, 943, 234, 38793] }

La variable image contiendra alors les propriétés Width, Height, Title, etc...

J'ai eu envie aujourd'hui de regarder exactement ce que signifie JSON est-ce une norme ? une RFC ? rien de tout ça ?

Après une rapide recherche je suis tombé sur la RFC 4627 :

RFC 4627 : The application/json Media Type for JavaScript Object Notation (JSON)

Voici deux passages qui m'ont marqué :

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

Qu'est-ce que cela veut dire ? que la clé, le nom de la propriété, doit être de type String. Ainsi :

var image = { maProp : 5 }

Bien qu'entièrement fonctionnel ce n'est pas du vrai JSON . L'exemple du dessous quand a lui est du vrai JSON.

var image = { "maProp" : 5 }

Rien de bien méchant mais je ne savais pas que c'était spécifié dans la norme. Par contre le second point est plus intéressant :

A JSON value MUST be an object, array, number, or string, or one of the following three literal names: false null true

ARGGG !!!

var params = { centerPoint : new Itelios.Geo.Point('04°49\'57"" ','46°18\'26"" ') }

Bien que 100% fonctionnel l'exemple du dessus n'est pas un exemple valide de JSON. Pourtant c'est très utile pour faire transiter un objet entre le client et le serveur, en effet le type Itelios.Geo.Point possède des méthodes sympas et c'est beaucoup plus qu'un simple objet qui contient seulement deux propriétés latitude et longitude. Je veux que ma variable params contienne une propriété centerPoint de type Itelios.Geo.Point malheureusement ce n'est pas possible avec JSON.

Mais quelles sont les raisons ? Pourquoi ne doit-on pas utiliser de type complexe dans du JSON ? C'est assez simple JSON est une notation qui permet de se représenter un objet complexe. Si l'on doit créer une instance d'un objet pour se le représenter, ce n'est plus vraiment une représentation de l'objet.

C'est décidé je n'aime plus JSON !

Microsoft Ajax Extensions (aka Atlas) implémente JSON correctement en respectant parfaitement les standards et c'est d'ailleurs un de mes problèmes j'en ai d'ailleurs parlé ici : Ajax Beta et serialization JSON. Je comprends le choix de l'équipe Atlas : ils veulent respecter les standards et blablabla c'est une bonne chose mais je n'approuve pas ce choix ! Pour moi le standard JSON ne me convient pas, il peut être utile dans certains cas, mais pourquoi ne pas inventer une écriture ? un JSON qui autoriserai les type complexe ? Avoir dans Atlas deux serializer, un pour du vrai JSON et un autre pour du "faux" JSON. Dans la CTP de Juillet JSON était implémenté intelligemment a mon avis il devait y avoir de bonnes raisons, c'est dommage de pas simplement avoir renommé l'ancien serializer et créer un nouveau plutôt que d'avoir supprimé l'ancien qui était fort utile.

Dans beaucoup de cas, cela va me bloquer, me limiter, et au final je vais être obligé de réécrire pas mal de choses qui étaient présente dans la CTP de juillet ...

Et vous qu'en pensez vous ? pour ou contre le -faux JSON- celui qui respecte pas la "norme" mais celui qui va bien ?

Posted: mercredi 20 décembre 2006 00:47 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

Poppyto a dit :

Pour JSON qui respecte la norme. (maintenant que tu as goûté au faux, c'est dûr de revenir en arrirèe hein? :) ).

Pour un Atlas moins gourmand aussi...

# décembre 20, 2006 10:44

FREMYCOMPANY a dit :

Poppyto : Je ne suis pas d'accord avec toi...

Atlas est plus gourmand quand il respect JSON (Plus de données envoyées et recues, plus d'objets à anlayser, sérialisations longue inutiles, erreur de context possibles (pour ceux qui ne connaissent pas la notion de contexte en JS : http://jibbering.com/faq/faq_notes/closures.html), et j'en passe!)

Franchement, JSON est très bien si il est "épuré" des règles inutiles...

Les standards aident si ils sont des avancées, pas des barrières...

Je developpe actuellement un FrameWork POO en JS, et, bien qu'en "standard" on applique le vrai JSON, il est possible (et même conseillé) pour celui qui crée des classes de les équiper de méthodes de sérialisations non-standard !

D'ailleurs JSON veut dire JavaScript Object Notation... pour moi, tout ce qui est valide pour JS devrait l'être pour JS, dans les mesures du raisonnable...

# décembre 20, 2006 12:05

FREMYCOMPANY a dit :

Désolé pour la précipitation, et pour mes fautes d'orthographes, mais c'est un sujet qui me tient à coeur... Voici quelques petites corrections :

"sérialisations [[longues et]] inutiles"

"D'ailleurs JSON veut dire JavaScript Object Notation... pour moi, tout ce qui est valide pour JS devrait l'être pour [[JSON]], dans les mesures du raisonnable..."

# décembre 20, 2006 12:15

cyril a dit :

FremyCompany > je suis pas d'accord avec toi JSON permet de faire transiter des objets, avec mon exemple il faudrais créer une instance d'un objet donc avoir le type, comment fais tu transiter le type ?

Pour reprendre la comparaison qu'Aurel vient de me dire : un json c'est comme un datareader, c'est une représentation des données !

C'est pour ça que je n'aime plus JSON ! JSON a été concu dans un autre usage que celui que je veux ! c'est décidé : je vais écrire une nouvelle RFC ;-)

Je pense qu'Atlas aurait du être livré avec 2 serializer. Un interne ils devraient utiliser la notation "intelligente" pour les scriptsDescriptor et laisser le choix via un attribut pour les PageMethods/WebService/etc...

# décembre 20, 2006 12:45

FREMYCOMPANY a dit :

La tu en arrives à un problème de compatibilité avec un language serveur... Ca c'est encore autre chose...

A la base JSON a été prévu pour et par JS...

Ainsi, le but de la sérialisation JSON est de, par exemple, stocker un objet JS dans un cookie temoraire, et le réouvrir dans la page suivante.

Dans ce cas, tous les types JS de la page de départ étant bien présents à la page d'arrivée, il n'y a aucun problème !

Evidement, pour ce qui est de transmettre des données de JS vers ASP .Net, c'est plus complexe... mais pas impossible !

Si les types ASP .Net et JS sont commums (même position dans la reflection (System.MyClass,par exemple), et bien, il est possible, en .Net d'émuler une fonction "eval" (je l'ai déjà fait, ca marche bien, mais c'est moins pratique qu'en JS ou PHP, vu le fort typage de .Net)... Ainsi, un classe peut être instanciée via .Net !

Et inversément, la classe .Net peut se serialiser pour JS, en utilsant la métode inverse (ca ca existe déjà et ce n'est pas difficile à mettre en place)

# décembre 20, 2006 12:55

cyril a dit :

Je suis pas d'accord JSON rempli parfaitement son but, et dans son but il ne devrait pas y avoir d'instance d'objet !

Pour ce qui est de transmettre des données de JS vers ASP.net C'ETAIT possible avec la CTP de July grace aux JavaScriptConverter mais ce n'est plus le cas ! et c'est bien là le problème, comme je l'ai dit plus haut ils auraient du mettre 2 serializer puis nous laisser le choix !

# décembre 20, 2006 14:22

FREMYCOMPANY a dit :

Je n'ai pas dit que JSON ne remplissait pas son but, j'ai dit qu'il ne permettait pas d'aller au-delà...

Or, bien souvent, on ne veut pas seulement stocker des données "brute" mais des objets, ce qui n'est pas possible avec le JSON "brut"...

Si il s'agit de stocker des données, XML le fait très bien... Alors pourquoi inventer de nouveaux outils qui, finalement, ne permettent pas plus que les outils qui existaient déjà avant, qui eux, sont gérés nativement par 1) Le navigateur 2) Les langages serveurs

Je rappeles en passant qu'une telle sérialisation d'objets existe sous forme de XML : le SOAP.

Et lui permet d'appeler des constructeurs (indirectement) car il exécute lors de la "reconstitution" une fonction qui réattribue des fonctions à l'objet généré...

FireFox permet d'ailleurs la (dé)sérialisation SOAP pour communiquer avec un service web, mais comme IE ne le permet pas, c'est inutile...

# décembre 20, 2006 14:48

FREMYCOMPANY a dit :

J'ai retrouvé l'article concernant la gestion du SOAP sous FireFox : http://developer.mozilla.org/fr/docs/SOAP_dans_les_navigateurs_Gecko

# décembre 20, 2006 15:03

cyril a dit :

Tu te contredis là, JSON est plus que du XML car il est compatible avec n'importe quelle interpréteur JavaScript, c'est la son point fort ... Ce n'est pas forcément le cas avec XML et puis c'est beaucoup plus compliqué et lent ... JSON est une avancé sur ce point de vue !

Quand au SOAP dans Firefox, Mozilla me fera toujours rire ! L'un des principaux reproches fait à IE est qu'il utilisait des objets non standard (ActiveX) Firefox est en train de suivre le même chemin ...

# décembre 20, 2006 15:32

FREMYCOMPANY a dit :

XML aussi est compatible avec n'importe quel interpréteur JS... Et l'avantage du XML est qu'il l'est aussi par .Net, Java, PHP, C, C++, ... JSON lui ne l'est que "via" une classe pas vraiment hyper-performante... Et de toute facon SOAP est mille fois plus efficace que JSON pour la transition d'objet... Si JSON ne permet pas autant que SOAP, il finira par arrêter d'être utilisé, une fois l'objet SOAP de FF standarisé...

Et je ne crois pas m'être contredit, vu que le but de JSON était le stockage sous forme standarisée de données, pas d'objet... Mais tout cela n'est qu'une question de point de vue... peut-on considerer une donnée comme un objet ? Personnelement, je ne crois pas... Ce qui n'empeche pas l'un d'être convertible en l'autre, et vis et versa... (C'est un peu comme comparer Char et Byte, on peut stocker un char dans un byte (et encore pas tjrs, mais bon soit) et un byte dans un char. Est-ce pour autant la meme chose ?

Je ne dénigre pas JSON, j'en montre la limite... limite de principe qui plus est...

# décembre 20, 2006 15:48

Aurelien a dit :

[quote]

FireFox permet d'ailleurs la (dé)sérialisation SOAP pour communiquer avec un service web, mais comme IE ne le permet pas, c'est inutile...

[/quote]

Je suis pas tellement d'accord sur ce point, Microsoft fourni depuis l'année 2000 le Behavior WebService permettant la communication SOAP/WebService. Tu trouveras ce behavior à l'adresse suivante : http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/samples/internet/behaviors/library/webservice/default.asp

Et en fouillant un poil dans la doc, on tombe sur ceci :

In addition to the entries in the table, other data types supported by ASP.NET Web services are also supported by the WebService behavior. XML objects, classes, structures, arrays of structures, and arrays of primitive data types can be returned from Web services, and the WebService behavior exposes them as scriptable objects, which can be referenced from the result object.

Au final, qui de la poule ou l'oeuf est arrivé le premier ?? Ok, je sors, je ne lance pas le Troll de Noël :)

# décembre 20, 2006 16:34

FREMYCOMPANY a dit :

Intéressant, mais encore une fois, pas standarisé = pas utilisé (du moins c'est à espérer)

# décembre 20, 2006 17:10

Aurelien a dit :

Pourquoi parles-tu de standard ?

Je ne l'ai pas fait, j'ai juste préciser que tes propos n'était pas correct et que Internet Explorer permettait aussi de le faire !

[quote]

Intéressant, mais encore une fois, pas standarisé = pas utilisé (du moins c'est à espérer)

[/quote]

Tu esperes donc que l'on n'utilise pas Ajax car XmlHttpRequest n'est pas un standard ?

# décembre 20, 2006 17:43

FREMYCOMPANY a dit :

La on m'a pris au mot ;)

Effectivement XMLHttpRequest n'est pas un standard... mais il marche sur IE et FireFox, ce qui suffit pour faire de lui un objet "standarisé".

["Je ne l'ai pas fait, j'ai juste préciser que tes propos n'était pas correct et que Internet Explorer permettait aussi de le faire !"]

J'avais compris ta démarche, et j'aprécie, car c'est avec ce genre de critique qu'on avance. En effet, je n'étais pas au courrant de cette initiative de la part de MS. Néamoins, tous ce qui n'est pas un minimum compatible est prohibé pour un "bon" site...

Je me trompe ?

# décembre 20, 2006 18:06
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01