<a href="javascript:void(0)" onMouseOver="return overlib('<img src=nom.jpg
>',RELX, -150,RELY, -20)" onMouseOut="return nd()"><b>toto</b></a>
(une image s'affiche quand la souris survole le nom toto)
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer) - c'est lisible et éditable par un être humain.
Bonjour,
J'avais compris que JSON était un moyen de transférer des données par XMLHttpRequest moins "volumineux" que XML.
C'est le cas - ou plus exactement, c'est une des utilisations possibles de JSON. Au lieu de sérialiser les données en XML, on les sérialise en JSON.
Et qu'il fallait de quoi "coder" dasn un sens et "décoder" dans l'autre.
Côté client (javascript), un simple eval() suffit, puisque le format JSON *est* du javascript. Côté serveur (a priori un autre langage, ie PHP, Perl, Python, Ruby, Java etc), il faut effectivement une bibliothèque pour encoder (essentiellement) et décoder (plus rarement nécessaire dans ce cas d'utilisation...). Ces bibliothèques existent déjà pour bon nombre de langages, dont Ruby, Perl, Python, PHP, C#, C++, C, Java, Erlang, Lua, OCaml, Common Lisp etc...
A vous lire j'ai l'impression d'avoir compris de travers ?
Ah bon ? Pourquoi ? A la relecture, je ne vois pas ce qui pourrait contredire ce point de vue dans mon post précédent ???
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Pierre Goiffon wrote:
Bruno Desthuilliers wrote:
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que:
- c'est facile à générer depuis n'importe quel langage (côté serveur)
- c'est du javascript valide, il n'y a donc aucun parsing à faire (côté
client)
- c'est moins verbeux que XML (donc moins d'octets à transférer)
- c'est lisible et éditable par un être humain.
Bonjour,
J'avais compris que JSON était un moyen de transférer des données par
XMLHttpRequest moins "volumineux" que XML.
C'est le cas - ou plus exactement, c'est une des utilisations possibles
de JSON. Au lieu de sérialiser les données en XML, on les sérialise en JSON.
Et qu'il fallait de quoi
"coder" dasn un sens et "décoder" dans l'autre.
Côté client (javascript), un simple eval() suffit, puisque le format
JSON *est* du javascript. Côté serveur (a priori un autre langage, ie
PHP, Perl, Python, Ruby, Java etc), il faut effectivement une
bibliothèque pour encoder (essentiellement) et décoder (plus rarement
nécessaire dans ce cas d'utilisation...). Ces bibliothèques existent
déjà pour bon nombre de langages, dont Ruby, Perl, Python, PHP, C#, C++,
C, Java, Erlang, Lua, OCaml, Common Lisp etc...
A vous lire j'ai l'impression d'avoir compris de travers ?
Ah bon ? Pourquoi ? A la relecture, je ne vois pas ce qui pourrait
contredire ce point de vue dans mon post précédent ???
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer) - c'est lisible et éditable par un être humain.
Bonjour,
J'avais compris que JSON était un moyen de transférer des données par XMLHttpRequest moins "volumineux" que XML.
C'est le cas - ou plus exactement, c'est une des utilisations possibles de JSON. Au lieu de sérialiser les données en XML, on les sérialise en JSON.
Et qu'il fallait de quoi "coder" dasn un sens et "décoder" dans l'autre.
Côté client (javascript), un simple eval() suffit, puisque le format JSON *est* du javascript. Côté serveur (a priori un autre langage, ie PHP, Perl, Python, Ruby, Java etc), il faut effectivement une bibliothèque pour encoder (essentiellement) et décoder (plus rarement nécessaire dans ce cas d'utilisation...). Ces bibliothèques existent déjà pour bon nombre de langages, dont Ruby, Perl, Python, PHP, C#, C++, C, Java, Erlang, Lua, OCaml, Common Lisp etc...
A vous lire j'ai l'impression d'avoir compris de travers ?
Ah bon ? Pourquoi ? A la relecture, je ne vois pas ce qui pourrait contredire ce point de vue dans mon post précédent ???
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ASM
ASM wrote: (snip)
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications deux-point-zéro placent de la "logique métier" coté navigateur et déclenchent des actions avec XHR. Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
Brefle je résume les notions client-side et serveur-side par JS / PHP (je sais c'est pô bien étoussa étoussa)
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus 1ko pour un max de possibilités
Ce qui me gène c'est le eval()
L'autre chose qui me gène est : et sans JS ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations. (y a tt de même de quoi s'y perdre)
-- ASM
ASM wrote:
(snip)
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications
deux-point-zéro placent de la "logique métier" coté navigateur et
déclenchent des actions avec XHR.
Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
Brefle je résume les notions client-side et serveur-side par JS / PHP
(je sais c'est pô bien étoussa étoussa)
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que:
- c'est facile à générer depuis n'importe quel langage (côté serveur)
- c'est du javascript valide, il n'y a donc aucun parsing à faire (côté
client)
- c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus
1ko pour un max de possibilités
Ce qui me gène c'est le eval()
L'autre chose qui me gène est : et sans JS ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations.
(y a tt de même de quoi s'y perdre)
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications deux-point-zéro placent de la "logique métier" coté navigateur et déclenchent des actions avec XHR. Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
Brefle je résume les notions client-side et serveur-side par JS / PHP (je sais c'est pô bien étoussa étoussa)
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus 1ko pour un max de possibilités
Ce qui me gène c'est le eval()
L'autre chose qui me gène est : et sans JS ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations. (y a tt de même de quoi s'y perdre)
-- ASM
JLM
Tu fais comme tu veux, mais n'en dégoûte pas les autres !
Le JS est souvent utilisé n'importe comment mais à part des disfonctionnements ça ne porte pas à d'autres conséquences. Pour le php il n'en va pas de même : les bons fonctionnements apparents peuvent conduire à de graves conséquences.
Alors, oui, quand je vois du html pourri je gueule à l'arnaque quant au php qui pourrait l'avoir pondu, et par voie de conséquence je doute des compétences du gus qui manipule ce php et suis prêt à tout pour l'en dégouter.
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ? D'autre part, le fait de générer du HTML pourri ne signifie pas que le script PHP par exemple soit mal écrit ...
Tu fais
comme tu veux, mais n'en dégoûte pas les autres !
Le JS est souvent utilisé n'importe comment mais à part des
disfonctionnements ça ne porte pas à d'autres conséquences.
Pour le php il n'en va pas de même : les bons fonctionnements apparents
peuvent conduire à de graves conséquences.
Alors, oui, quand je vois du html pourri je gueule à l'arnaque quant au
php qui pourrait l'avoir pondu, et par voie de conséquence je doute des
compétences du gus qui manipule ce php et suis prêt à tout pour l'en
dégouter.
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ?
D'autre part, le fait de générer du HTML pourri ne signifie pas que le
script PHP par exemple soit mal écrit ...
Tu fais comme tu veux, mais n'en dégoûte pas les autres !
Le JS est souvent utilisé n'importe comment mais à part des disfonctionnements ça ne porte pas à d'autres conséquences. Pour le php il n'en va pas de même : les bons fonctionnements apparents peuvent conduire à de graves conséquences.
Alors, oui, quand je vois du html pourri je gueule à l'arnaque quant au php qui pourrait l'avoir pondu, et par voie de conséquence je doute des compétences du gus qui manipule ce php et suis prêt à tout pour l'en dégouter.
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ? D'autre part, le fait de générer du HTML pourri ne signifie pas que le script PHP par exemple soit mal écrit ...
Olivier Miakinen
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ? D'autre part, le fait de générer du HTML pourri ne signifie pas que le script PHP par exemple soit mal écrit ...
... et réciproquement.
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ?
D'autre part, le fait de générer du HTML pourri ne signifie pas que le
script PHP par exemple soit mal écrit ...
Qu'utilises-tu généralement pour générer du code dynamique du côté serveur ? D'autre part, le fait de générer du HTML pourri ne signifie pas que le script PHP par exemple soit mal écrit ...
... et réciproquement.
Bruno Desthuilliers
ASM wrote:
ASM wrote: (snip)
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications deux-point-zéro placent de la "logique métier" coté navigateur et déclenchent des actions avec XHR. Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
L'appel au serveur via l'objet XmlHttpRequest et le traitement de la réponse se font côté client - donc en Javascript. Avec ça, il est possible de déplacer l'essentiel du controleur vers le client.
Quant à ce qui se passe côté serveur, que ce soit géré par du PHP, du Python ou des petits lutins, c'est complètement orthogonal.
Brefle je résume les notions client-side et serveur-side par JS / PHP (je sais c'est pô bien étoussa étoussa)
Il est clair que côté client, on n'a pas grand chose d'autre que javascript. Côté serveur, il y a heureusement pas mal d'autres possibilités que PHP.
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus 1ko pour un max de possibilités
Ce qui me gène c'est le eval()
Si la source est connue et fiable, ce n'est pas un problème. Et comme l'objet XmlHttpRequest ne peut a priori pas appeler d'autre domaine que celui d'origine, et que les parties les plus "sensibles" du code sont côté serveur, je ne vois pas trop quel est le risque majeur - même à supposer qu'un code malicieux soit eval()'ué côté client...
Mais si tu es inquiet, il y a un décodeur JSON en javascript, qui si mon souvenir est bon évalue le fragment JSON dans un environnement restreint (pas de possibilité d'exécution de code).
L'autre chose qui me gène est : et sans JS ?
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un interpréteur javascript lancé. Etonnant, non ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations. (y a tt de même de quoi s'y perdre)
Pas plus que dans une soupe de tags XML...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ASM wrote:
ASM wrote:
(snip)
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications
deux-point-zéro placent de la "logique métier" coté navigateur et
déclenchent des actions avec XHR.
Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
L'appel au serveur via l'objet XmlHttpRequest et le traitement de la
réponse se font côté client - donc en Javascript. Avec ça, il est
possible de déplacer l'essentiel du controleur vers le client.
Quant à ce qui se passe côté serveur, que ce soit géré par du PHP, du
Python ou des petits lutins, c'est complètement orthogonal.
Brefle je résume les notions client-side et serveur-side par JS / PHP
(je sais c'est pô bien étoussa étoussa)
Il est clair que côté client, on n'a pas grand chose d'autre que
javascript. Côté serveur, il y a heureusement pas mal d'autres
possibilités que PHP.
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que:
- c'est facile à générer depuis n'importe quel langage (côté serveur)
- c'est du javascript valide, il n'y a donc aucun parsing à faire (côté
client)
- c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus
1ko pour un max de possibilités
Ce qui me gène c'est le eval()
Si la source est connue et fiable, ce n'est pas un problème. Et comme
l'objet XmlHttpRequest ne peut a priori pas appeler d'autre domaine que
celui d'origine, et que les parties les plus "sensibles" du code sont
côté serveur, je ne vois pas trop quel est le risque majeur - même à
supposer qu'un code malicieux soit eval()'ué côté client...
Mais si tu es inquiet, il y a un décodeur JSON en javascript, qui si mon
souvenir est bon évalue le fragment JSON dans un environnement restreint
(pas de possibilité d'exécution de code).
L'autre chose qui me gène est : et sans JS ?
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un
interpréteur javascript lancé. Etonnant, non ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations.
(y a tt de même de quoi s'y perdre)
Pas plus que dans une soupe de tags XML...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications deux-point-zéro placent de la "logique métier" coté navigateur et déclenchent des actions avec XHR. Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
Et ? Ca reste du javascript, non ?
Non, à mon idée ça devient du PHP (enfin ... des fois)
L'appel au serveur via l'objet XmlHttpRequest et le traitement de la réponse se font côté client - donc en Javascript. Avec ça, il est possible de déplacer l'essentiel du controleur vers le client.
Quant à ce qui se passe côté serveur, que ce soit géré par du PHP, du Python ou des petits lutins, c'est complètement orthogonal.
Brefle je résume les notions client-side et serveur-side par JS / PHP (je sais c'est pô bien étoussa étoussa)
Il est clair que côté client, on n'a pas grand chose d'autre que javascript. Côté serveur, il y a heureusement pas mal d'autres possibilités que PHP.
(snip)
Et parlons d'autre chose, alors ce JSON ?
JSON n'est rien de plus qu'un format de sérialisation "light". Ses
principaux intérêts sont que: - c'est facile à générer depuis n'importe quel langage (côté serveur) - c'est du javascript valide, il n'y a donc aucun parsing à faire (côté client) - c'est moins verbeux que XML (donc moins d'octets à transférer)
c'est ça qui me bluffe le plus 1ko pour un max de possibilités
Ce qui me gène c'est le eval()
Si la source est connue et fiable, ce n'est pas un problème. Et comme l'objet XmlHttpRequest ne peut a priori pas appeler d'autre domaine que celui d'origine, et que les parties les plus "sensibles" du code sont côté serveur, je ne vois pas trop quel est le risque majeur - même à supposer qu'un code malicieux soit eval()'ué côté client...
Mais si tu es inquiet, il y a un décodeur JSON en javascript, qui si mon souvenir est bon évalue le fragment JSON dans un environnement restreint (pas de possibilité d'exécution de code).
L'autre chose qui me gène est : et sans JS ?
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un interpréteur javascript lancé. Etonnant, non ?
- c'est lisible et éditable par un être humain.
Qui sait bien lire les bracket notations. (y a tt de même de quoi s'y perdre)
Pas plus que dans une soupe de tags XML...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Pierre Goiffon
Bruno Desthuilliers wrote:
Bonjour,
J'avais compris que JSON était un moyen de transférer des données par XMLHttpRequest moins "volumineux" que XML.
C'est le cas (...)
Merci à vous de toutes ces précisions !
Bruno Desthuilliers wrote:
Bonjour,
J'avais compris que JSON était un moyen de transférer des données par
XMLHttpRequest moins "volumineux" que XML.
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un interpréteur javascript lancé. Etonnant, non ?
Heu, normalement tu lances un appel au serveur (href ou action) en "traditionnel", le XHR n'est lancé que si JS.
Si le XHR active JSON, je crains que le "traditionnel" puisse nécessiter un gros boulot (équivalent PHP/ASP/truc de JSON à doubler)
- c'est lisible et éditable par un être humain. Qui sait bien lire les bracket notations.
(y a tt de même de quoi s'y perdre)
Pas plus que dans une soupe de tags XML...
de quoi ? un potage de tailles extra moyennement larges ?
(bon ... pas drôle ... on fait c'qu'on peut)
Pierre Goiffon
Bruno Desthuilliers wrote:
J'avais compris que JSON était un moyen de transférer des données par XMLHttpRequest moins "volumineux" que XML. C'est le cas
(...)
Merci à vous de toutes ces précisions !
Toutes ces infos sont disponibles sur le net, et fort peu difficiles à trouver...
http://json.org
Je suis bien entendu allé sur ce site (entre autre), il ne répondait pas à mes questions Pour vous en convaincre, comparez votre petit topo précédent qui m'a été fort utile avec le contenu de la page d'accueil du site...
Merci encore en tout cas d'avoir répondu à mes questions - je n'utiliserai peut être pas json tout de suite, mais au moins j'ai une idée de son usage possible
Bruno Desthuilliers wrote:
J'avais compris que JSON était un moyen de transférer des données par
XMLHttpRequest moins "volumineux" que XML.
C'est le cas
(...)
Merci à vous de toutes ces précisions !
Toutes ces infos sont disponibles sur le net, et fort peu difficiles à
trouver...
http://json.org
Je suis bien entendu allé sur ce site (entre autre), il ne répondait pas
à mes questions
Pour vous en convaincre, comparez votre petit topo précédent qui m'a été
fort utile avec le contenu de la page d'accueil du site...
Merci encore en tout cas d'avoir répondu à mes questions - je
n'utiliserai peut être pas json tout de suite, mais au moins j'ai une
idée de son usage possible
J'avais compris que JSON était un moyen de transférer des données par XMLHttpRequest moins "volumineux" que XML. C'est le cas
(...)
Merci à vous de toutes ces précisions !
Toutes ces infos sont disponibles sur le net, et fort peu difficiles à trouver...
http://json.org
Je suis bien entendu allé sur ce site (entre autre), il ne répondait pas à mes questions Pour vous en convaincre, comparez votre petit topo précédent qui m'a été fort utile avec le contenu de la page d'accueil du site...
Merci encore en tout cas d'avoir répondu à mes questions - je n'utiliserai peut être pas json tout de suite, mais au moins j'ai une idée de son usage possible
Bruno Desthuilliers
ASM wrote:
ASM wrote:
L'autre chose qui me gène est : et sans JS ?
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un interpréteur javascript lancé. Etonnant, non ?
Heu, normalement tu lances un appel au serveur (href ou action)
Bref, une requête HTTP.
en "traditionnel", le XHR n'est lancé que si JS.
Effectivement, XmlHttpRequest étant un composannt javascript, il ne sert pas à grand chose si javascript est désactivé. Ce qui est une simple reformulation de mon observation précédente !-)
Si le XHR active JSON,
L'object XmlHttpRequest "n'active" rien, et la notion d'"activation" n'a aucun sens ici. JSON est *un format de données*, pas un composant logiciel.
je crains que le "traditionnel" puisse nécessiter un gros boulot (équivalent PHP/ASP/truc de JSON à doubler)
Si tu veux que l'appli fonctionne sans javascript, il est effectivement préférable de commencer par la faire fonctionner sans. Et il y a effectivement le risque de se retrouver à dupliquer certains formatages entre la partie client et la partie serveur. Dans ce cas, il peut être préférable de se passer de JSON - le code serveur retourne un fragment de html, le code client se contente d'insérer ce fragment dans le document (ou de remplacer un élément du document par ledit fragment html).
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ASM wrote:
ASM wrote:
L'autre chose qui me gène est : et sans JS ?
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un
interpréteur javascript lancé. Etonnant, non ?
Heu, normalement tu lances un appel au serveur (href ou action)
Bref, une requête HTTP.
en
"traditionnel", le XHR n'est lancé que si JS.
Effectivement, XmlHttpRequest étant un composannt javascript, il ne sert
pas à grand chose si javascript est désactivé. Ce qui est une simple
reformulation de mon observation précédente !-)
Si le XHR active JSON,
L'object XmlHttpRequest "n'active" rien, et la notion d'"activation" n'a
aucun sens ici. JSON est *un format de données*, pas un composant logiciel.
je crains que le "traditionnel" puisse nécessiter
un gros boulot (équivalent PHP/ASP/truc de JSON à doubler)
Si tu veux que l'appli fonctionne sans javascript, il est effectivement
préférable de commencer par la faire fonctionner sans. Et il y a
effectivement le risque de se retrouver à dupliquer certains formatages
entre la partie client et la partie serveur. Dans ce cas, il peut être
préférable de se passer de JSON - le code serveur retourne un fragment
de html, le code client se contente d'insérer ce fragment dans le
document (ou de remplacer un élément du document par ledit fragment html).
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Une particularité de javascript, c'est que ça ne fonctionne qu'avec un interpréteur javascript lancé. Etonnant, non ?
Heu, normalement tu lances un appel au serveur (href ou action)
Bref, une requête HTTP.
en "traditionnel", le XHR n'est lancé que si JS.
Effectivement, XmlHttpRequest étant un composannt javascript, il ne sert pas à grand chose si javascript est désactivé. Ce qui est une simple reformulation de mon observation précédente !-)
Si le XHR active JSON,
L'object XmlHttpRequest "n'active" rien, et la notion d'"activation" n'a aucun sens ici. JSON est *un format de données*, pas un composant logiciel.
je crains que le "traditionnel" puisse nécessiter un gros boulot (équivalent PHP/ASP/truc de JSON à doubler)
Si tu veux que l'appli fonctionne sans javascript, il est effectivement préférable de commencer par la faire fonctionner sans. Et il y a effectivement le risque de se retrouver à dupliquer certains formatages entre la partie client et la partie serveur. Dans ce cas, il peut être préférable de se passer de JSON - le code serveur retourne un fragment de html, le code client se contente d'insérer ce fragment dans le document (ou de remplacer un élément du document par ledit fragment html).
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
