Le traitement de la requête par php lance un preg_replace, et c'est là
que j'ai longtemps tourné en rond, jusqu'à découvrir que :
Si mon code source HTML utilise les guillements simples pour les
attributs
name='Nom' ,
*innerHTML* me renvoie le source avec les guillements doubles
name="Nom" !!!
le php fait sa cuisine vers BdD et pond le nouveau form (ça reste du basique php, pas besoin de se compliquer la vie)
Je voulais que Php ne ponde que les données (XML?) pour que ce soit plus léger, et qu'elles soient intégrées au formulaire HTML par le JavaScript. Mais cette méthode ne serait pas préconisée ?
Je dois avouer ne m'être pas (encore) mis au XML :-/ De ce que j'y comprends : le xml n'est qu'une autre façon de tartiner des balises ...
sinon en JS tradi : document.monForm.monChamp.value = <?= $champ[] ?>;
Je ne sais pas si on peut vraiment appeler ça de l'AjaX ? c'est du XMLHttpRequest vers un fichier (intelligent) en php
Ben je croyais qu'AJAX était Requete XML et Javascript asynchrones. Donc correspondant à ça...
Pour ne faire que ça, ça me semble bien peu par rapport à ce que des biblis AjaX peuvent faire (où tout ne fonctionne que par JS standard + asynchone + asp, php, cgi, BdD).
http://www.ajaxtoolbox.com/
Avez-vous un script qui distribuerait ces infos dans les VALUEs ? Aucune utilité, c'est tellement plus sûr
et aussi vite fait côté serveur !
OK. J'avais l'impression d'avoir plus de modularité...
Pour plus de modularité tu n'as qu'à ne t'interesser que champ après champ ? http://www.ajaxtoolbox.com/request/examples.php
function verif(quoi) { var lieu = quoi.parentNode; var quant = quoi.name; monAjaxRequete(lieu,quoi,'calcul_champ.php'); }
et pour verif() inspiration : <http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-2.shtml> <http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-1.shtml>
-- ASM
ASM avait énoncé :
le php fait sa cuisine vers BdD et pond le nouveau form
(ça reste du basique php, pas besoin de se compliquer la vie)
Je voulais que Php ne ponde que les données (XML?) pour que ce soit plus
léger, et qu'elles soient intégrées au formulaire HTML par le JavaScript.
Mais cette méthode ne serait pas préconisée ?
Je dois avouer ne m'être pas (encore) mis au XML :-/
De ce que j'y comprends :
le xml n'est qu'une autre façon de tartiner des balises ...
sinon en JS tradi :
document.monForm.monChamp.value = <?= $champ[] ?>;
Je ne sais pas si on peut vraiment appeler ça de l'AjaX ?
c'est du XMLHttpRequest vers un fichier (intelligent) en php
Ben je croyais qu'AJAX était Requete XML et Javascript asynchrones.
Donc correspondant à ça...
Pour ne faire que ça, ça me semble bien peu par rapport à ce que des
biblis AjaX peuvent faire (où tout ne fonctionne que par JS standard +
asynchone + asp, php, cgi, BdD).
http://www.ajaxtoolbox.com/
Avez-vous un script qui distribuerait ces infos dans les VALUEs ?
Aucune utilité, c'est tellement plus sûr
et aussi vite fait côté serveur !
OK. J'avais l'impression d'avoir plus de modularité...
Pour plus de modularité tu n'as qu'à ne t'interesser que champ après champ ?
http://www.ajaxtoolbox.com/request/examples.php
function verif(quoi) {
var lieu = quoi.parentNode;
var quant = quoi.name;
monAjaxRequete(lieu,quoi,'calcul_champ.php');
}
et pour verif() inspiration :
<http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-2.shtml>
<http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-1.shtml>
le php fait sa cuisine vers BdD et pond le nouveau form (ça reste du basique php, pas besoin de se compliquer la vie)
Je voulais que Php ne ponde que les données (XML?) pour que ce soit plus léger, et qu'elles soient intégrées au formulaire HTML par le JavaScript. Mais cette méthode ne serait pas préconisée ?
Je dois avouer ne m'être pas (encore) mis au XML :-/ De ce que j'y comprends : le xml n'est qu'une autre façon de tartiner des balises ...
sinon en JS tradi : document.monForm.monChamp.value = <?= $champ[] ?>;
Je ne sais pas si on peut vraiment appeler ça de l'AjaX ? c'est du XMLHttpRequest vers un fichier (intelligent) en php
Ben je croyais qu'AJAX était Requete XML et Javascript asynchrones. Donc correspondant à ça...
Pour ne faire que ça, ça me semble bien peu par rapport à ce que des biblis AjaX peuvent faire (où tout ne fonctionne que par JS standard + asynchone + asp, php, cgi, BdD).
http://www.ajaxtoolbox.com/
Avez-vous un script qui distribuerait ces infos dans les VALUEs ? Aucune utilité, c'est tellement plus sûr
et aussi vite fait côté serveur !
OK. J'avais l'impression d'avoir plus de modularité...
Pour plus de modularité tu n'as qu'à ne t'interesser que champ après champ ? http://www.ajaxtoolbox.com/request/examples.php
function verif(quoi) { var lieu = quoi.parentNode; var quant = quoi.name; monAjaxRequete(lieu,quoi,'calcul_champ.php'); }
et pour verif() inspiration : <http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-2.shtml> <http://developpeur.journaldunet.com/tutoriel/dht/050406-javascript-ajax-xmlhttprequest-1.shtml>
-- ASM
ASM
Avez-vous un script qui distribuerait ces infos dans les VALUEs ?
le pdf n'est pas très "jojo" mais quand même lisible sur Mac OS X :
<http://cjoint.com/data/khoHv1JUys.htm>
ouais, he ben il ne fait que kkbouiller avec mon plug-in de pdf de FF. et dans mon Acrobte-reader je ne peux rien copier pour essayer ... :-(
-- ASM
JLM
ASM a formulé la demande :
Très très mauvaise idée d'utiliser innerHTML !
Ah. :-/
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes : juste pour s'éviter d'échapper les " on met ' dans les instructions destinées à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets, et que j'ai plus souvent à échapper des apostrophes que des guillements. Je vais donc corriger mes sources html pour être conforme.
Non non, à plus forte raison si vous utilisez le XHTML. Le guillemet simple et double ont exactement le même comportement, ils peuvent être interchangeables. Donc c'est tout à fait valide d'utiliser le guillemet simple (c'est autorisé par la norme).
Le pb vient du navigateur, qui en interne ne tient pas compte du type de guillemet utilisé originalement. Il faut voir que l'arbre (X)HTML est stocké en interne sous la forme d'un arbre DOM ; le innerHTML demande la conversion d'une partie de cet arbre sous la forme d'une chaîne. FF a choisi d'utiliser les " pour encoder les délimiteurs d'attributs ; c'est un choix comme un autre. Normalement, tout serveur correctement codé doit savoir interpréter les deux types de guillemets indifféremment.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour - IE - autres brouteurs Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour le texte entre 2 balises.
OK.
Ah ben voilà un bon guide !! Merci :-)
ASM a formulé la demande :
Très très mauvaise idée d'utiliser innerHTML !
Ah. :-/
mon HTML utilise les guillements simples pour les attributs name='Nom' ,
*innerHTML* me renvoie les guillements doubles name="Nom" !!!
paske, normalement, en html c'est comme ça que ça s'écrit
La pratique du php donne de très mauvaises habitudes :
juste pour s'éviter d'échapper les " on met ' dans les instructions
destinées à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets,
et que j'ai plus souvent à échapper des apostrophes que des guillements.
Je vais donc corriger mes sources html pour être conforme.
Non non, à plus forte raison si vous utilisez le XHTML.
Le guillemet simple et double ont exactement le même comportement, ils
peuvent être interchangeables. Donc c'est tout à fait valide d'utiliser
le guillemet simple (c'est autorisé par la norme).
Le pb vient du navigateur, qui en interne ne tient pas compte du type de
guillemet utilisé originalement. Il faut voir que l'arbre (X)HTML est
stocké en interne sous la forme d'un arbre DOM ; le innerHTML demande la
conversion d'une partie de cet arbre sous la forme d'une chaîne. FF a
choisi d'utiliser les " pour encoder les délimiteurs d'attributs ; c'est
un choix comme un autre. Normalement, tout serveur correctement codé
doit savoir interpréter les deux types de guillemets indifféremment.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour
- IE - autres brouteurs
Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour
le texte entre 2 balises.
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes : juste pour s'éviter d'échapper les " on met ' dans les instructions destinées à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets, et que j'ai plus souvent à échapper des apostrophes que des guillements. Je vais donc corriger mes sources html pour être conforme.
Non non, à plus forte raison si vous utilisez le XHTML. Le guillemet simple et double ont exactement le même comportement, ils peuvent être interchangeables. Donc c'est tout à fait valide d'utiliser le guillemet simple (c'est autorisé par la norme).
Le pb vient du navigateur, qui en interne ne tient pas compte du type de guillemet utilisé originalement. Il faut voir que l'arbre (X)HTML est stocké en interne sous la forme d'un arbre DOM ; le innerHTML demande la conversion d'une partie de cet arbre sous la forme d'une chaîne. FF a choisi d'utiliser les " pour encoder les délimiteurs d'attributs ; c'est un choix comme un autre. Normalement, tout serveur correctement codé doit savoir interpréter les deux types de guillemets indifféremment.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour - IE - autres brouteurs Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour le texte entre 2 balises.
OK.
Ah ben voilà un bon guide !! Merci :-)
Olivier Miakinen
Très très mauvaise idée d'utiliser innerHTML !
Ah. :-/
Oui, c'est vrai, mais tu semblais le savoir puisque dans ton article initial tu as écrit « avant de faire mieux et plus propre ». innerHTML est reconnu par les navigateurs principaux, mais d'une part il n'est pas standard, et d'autre part son comportement est assez variable d'un navigateur à un autre lorsque le code inclus contient autre chose que du texte simple (donc quand il contient des balises HTML).
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides. De plus, si tu fournis au navigateur du code incorrect¹, il est possible qu'il te le corrige pour pouvoir le stocker dans son arbre DOM.
¹ Par exemple : <b><i>...</b></i>
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes : juste pour s'éviter d'échapper les " on met ' dans les instructions destinées à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets, et que j'ai plus souvent à échapper des apostrophes que des guillements. Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP, il a horreur de ce langage qu'il trouve trop compliqué et il ne manque pas une occasion de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec PHP.
Les guillemets simples '...' sont tout aussi valides que les guillemets doubles "...", aussi bien en SGML (HTML) qu'en XML (XHTML). Il y a juste que dans certains cas très particuliers il est possible d'omettre tout guillemet en HTML (mais pas en XHTML), pratique qui est malgré tout fortement déconseillée.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour - IE - autres brouteurs Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour le texte entre 2 balises.
Ça c'est absolument vrai.
Ah ben voilà un bon guide !!
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle de PHP. ;-)
Très très mauvaise idée d'utiliser innerHTML !
Ah. :-/
Oui, c'est vrai, mais tu semblais le savoir puisque dans ton article
initial tu as écrit « avant de faire mieux et plus propre ». innerHTML
est reconnu par les navigateurs principaux, mais d'une part il n'est
pas standard, et d'autre part son comportement est assez variable d'un
navigateur à un autre lorsque le code inclus contient autre chose que du
texte simple (donc quand il contient des balises HTML).
mon HTML utilise les guillements simples pour les attributs name='Nom' ,
*innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides. De plus, si tu fournis au
navigateur du code incorrect¹, il est possible qu'il te le corrige pour
pouvoir le stocker dans son arbre DOM.
¹ Par exemple : <b><i>...</b></i>
paske, normalement, en html c'est comme ça que ça s'écrit
La pratique du php donne de très mauvaises habitudes :
juste pour s'éviter d'échapper les " on met ' dans les instructions destinées
à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets,
et que j'ai plus souvent à échapper des apostrophes que des
guillements.
Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP, il a horreur de ce
langage qu'il trouve trop compliqué et il ne manque pas une occasion
de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec
PHP.
Les guillemets simples '...' sont tout aussi valides que les guillemets
doubles "...", aussi bien en SGML (HTML) qu'en XML (XHTML). Il y a juste
que dans certains cas très particuliers il est possible d'omettre tout
guillemet en HTML (mais pas en XHTML), pratique qui est malgré tout
fortement déconseillée.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour
- IE - autres brouteurs
Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour le
texte entre 2 balises.
Ça c'est absolument vrai.
Ah ben voilà un bon guide !!
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle
de PHP. ;-)
Oui, c'est vrai, mais tu semblais le savoir puisque dans ton article initial tu as écrit « avant de faire mieux et plus propre ». innerHTML est reconnu par les navigateurs principaux, mais d'une part il n'est pas standard, et d'autre part son comportement est assez variable d'un navigateur à un autre lorsque le code inclus contient autre chose que du texte simple (donc quand il contient des balises HTML).
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides. De plus, si tu fournis au navigateur du code incorrect¹, il est possible qu'il te le corrige pour pouvoir le stocker dans son arbre DOM.
¹ Par exemple : <b><i>...</b></i>
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes : juste pour s'éviter d'échapper les " on met ' dans les instructions destinées à l'echoyage ou au printage du html.
OK. Habitude de php car '...' et "..." n'ont pas pas les mêmes effets, et que j'ai plus souvent à échapper des apostrophes que des guillements. Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP, il a horreur de ce langage qu'il trouve trop compliqué et il ne manque pas une occasion de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec PHP.
Les guillemets simples '...' sont tout aussi valides que les guillemets doubles "...", aussi bien en SGML (HTML) qu'en XML (XHTML). Il y a juste que dans certains cas très particuliers il est possible d'omettre tout guillemet en HTML (mais pas en XHTML), pratique qui est malgré tout fortement déconseillée.
Il faut bien savoir que innerHTML n'a pas tout à fait le même sens pour - IE - autres brouteurs Pour être vraiment *propre* il faudrait n'utiliser innerHTML que pour le texte entre 2 balises.
Ça c'est absolument vrai.
Ah ben voilà un bon guide !!
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle de PHP. ;-)
ASM
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides.
Mais y en a un plus moche que l'autre (moins humainement lisible). Je vote pour les "
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes :
Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP,
Vu toutes les horreurs pondues grâce à cet outil non maitrisé ! (et qui vraiment blâmer avec 3172 fonctions ! dont bp en doublons) Ouais le PHP ... kof kof
et puis ... :-(
il a horreur de ce langage qu'il trouve trop compliqué et il ne manque pas une occasion de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec PHP.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ceux qui tripotent le PHP qui ne savent pas faire des échappements corrects. (ce qui laisse augurer du reste!)
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle de PHP. ;-)
J'envoie la 'tite url de circonstance ? http://stephane.moriaux.perso.orange.fr/gifs/
Et si tu passais corriger : <4526b2e5$0$27402$ <http://groups.google.com/group/fr.comp.lang.javascript/msg/98245a99486ec9c4?rnum=1>
-- ASM
mon HTML utilise les guillements simples pour les attributs name='Nom' ,
*innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides.
Mais y en a un plus moche que l'autre (moins humainement lisible).
Je vote pour les "
paske, normalement, en html c'est comme ça que ça s'écrit
La pratique du php donne de très mauvaises habitudes :
Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP,
Vu toutes les horreurs pondues grâce à cet outil non maitrisé !
(et qui vraiment blâmer avec 3172 fonctions ! dont bp en doublons)
Ouais le PHP ... kof kof
et puis ... :-(
il a horreur de ce
langage qu'il trouve trop compliqué et il ne manque pas une occasion
de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec
PHP.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ceux qui
tripotent le PHP qui ne savent pas faire des échappements corrects.
(ce qui laisse augurer du reste!)
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle
de PHP. ;-)
J'envoie la 'tite url de circonstance ?
http://stephane.moriaux.perso.orange.fr/gifs/
Et si tu passais corriger : <4526b2e5$0$27402$ba4acef3@news.orange.fr>
<http://groups.google.com/group/fr.comp.lang.javascript/msg/98245a99486ec9c4?rnum=1>
mon HTML utilise les guillements simples pour les attributs name='Nom' , *innerHTML* me renvoie les guillements doubles name="Nom" !!!
Pourquoi pas : les deux sont valides.
Mais y en a un plus moche que l'autre (moins humainement lisible). Je vote pour les "
paske, normalement, en html c'est comme ça que ça s'écrit La pratique du php donne de très mauvaises habitudes :
Je vais donc corriger mes sources html pour être conforme.
Pfff... n'écoute pas ASM quand il parle de PHP,
Vu toutes les horreurs pondues grâce à cet outil non maitrisé ! (et qui vraiment blâmer avec 3172 fonctions ! dont bp en doublons) Ouais le PHP ... kof kof
et puis ... :-(
il a horreur de ce langage qu'il trouve trop compliqué et il ne manque pas une occasion de taper dessus, quitte à dire des âneries qui n'ont rien à voir avec PHP.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ceux qui tripotent le PHP qui ne savent pas faire des échappements corrects. (ce qui laisse augurer du reste!)
ASM ? *Très* souvent, mais pas toujours, surtout pas quand on lui parle de PHP. ;-)
J'envoie la 'tite url de circonstance ? http://stephane.moriaux.perso.orange.fr/gifs/
Et si tu passais corriger : <4526b2e5$0$27402$ <http://groups.google.com/group/fr.comp.lang.javascript/msg/98245a99486ec9c4?rnum=1>
-- ASM
BertrandB
PHP.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ce ux qui tripotent le PHP qui ne savent pas faire des échappements corrects. (ce qui laisse augurer du reste!)
+1
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme ... . Ben c'est la grande époque de l'amstrad ... Heureusement de temps en temps il y a des développeur qui pondent des trucs très propres.
PHP.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ce ux qui
tripotent le PHP qui ne savent pas faire des échappements corrects.
(ce qui laisse augurer du reste!)
+1
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le
net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme ... .
Ben c'est la grande époque de l'amstrad ...
Heureusement de temps en temps il y a des développeur qui pondent des
trucs très propres.
Là, désolé, je n'ai pas dit d'annerie : il y a au moins 40% de ce ux qui tripotent le PHP qui ne savent pas faire des échappements corrects. (ce qui laisse augurer du reste!)
+1
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme ... . Ben c'est la grande époque de l'amstrad ... Heureusement de temps en temps il y a des développeur qui pondent des trucs très propres.
Olivier Miakinen
[ programmes écrits en XXX(¹) ]
+1
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme .... Ben c'est la grande époque de l'amstrad ... Heureusement de temps en temps il y a des développeur qui pondent des trucs très propres.
(¹) Dans l'article d'origine, on avait XXX = PHP. Mais cela vaut tout aussi bien pour JavaScript (j'essaye de rester un peu en charte) et pour C, C++, Java, lisp, et ainsi de suite. On peut même l'étendre aux langages de description tels que HTML par exemple.
[ programmes écrits en XXX(¹) ]
+1
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le
net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme ....
Ben c'est la grande époque de l'amstrad ...
Heureusement de temps en temps il y a des développeur qui pondent des
trucs très propres.
(¹) Dans l'article d'origine, on avait XXX = PHP. Mais cela vaut tout
aussi bien pour JavaScript (j'essaye de rester un peu en charte) et
pour C, C++, Java, lisp, et ainsi de suite. On peut même l'étendre aux
langages de description tels que HTML par exemple.
Pour y avoir mis le nez l'essentiel des sources que l'on trouve sur le net y compris pour de gros morceaux (ex yappa-ng) sont écrits comme .... Ben c'est la grande époque de l'amstrad ... Heureusement de temps en temps il y a des développeur qui pondent des trucs très propres.
(¹) Dans l'article d'origine, on avait XXX = PHP. Mais cela vaut tout aussi bien pour JavaScript (j'essaye de rester un peu en charte) et pour C, C++, Java, lisp, et ainsi de suite. On peut même l'étendre aux langages de description tels que HTML par exemple.
Roger (Bordeaux)
Avez-vous un script qui distribuerait ces infos dans les VALUEs ?
J'ai horreur des docs pdf (pour montrer du code) ! surtout quand ça me donne ça : http://cjoint.com/?khomAbYyP4
Il est très bien son pdf !!! Tu dois avoir un pb avec ton reader.
J'utilise Ajax depuis peu et ne suis ni un spécialiste du dev web ni de javascript.
Ce qui est marrant avec Ajax, c'est qu'on a pas forcément besoin d'utiliser XML comme format de réponse. JSON est pas mal non plus, plus léger et plus facile a utiliser à mon gout. En fait n'importe quoi peut techniquement convenir bien qu'il soit largement préférable d'utiliser un format structurer comme XML ou JSON.
A+
Roger
Avez-vous un script qui distribuerait ces infos dans les VALUEs ?
J'ai horreur des docs pdf (pour montrer du code) !
surtout quand ça me donne ça :
http://cjoint.com/?khomAbYyP4
Il est très bien son pdf !!! Tu dois avoir un pb avec ton reader.
J'utilise Ajax depuis peu et ne suis ni un spécialiste du dev web ni de
javascript.
Ce qui est marrant avec Ajax, c'est qu'on a pas forcément besoin
d'utiliser XML comme format de réponse. JSON est pas mal non plus, plus
léger et plus facile a utiliser à mon gout.
En fait n'importe quoi peut techniquement convenir bien qu'il soit
largement préférable d'utiliser un format structurer comme XML ou JSON.
J'ai horreur des docs pdf (pour montrer du code) ! surtout quand ça me donne ça : http://cjoint.com/?khomAbYyP4
Il est très bien son pdf !!! Tu dois avoir un pb avec ton reader.
J'utilise Ajax depuis peu et ne suis ni un spécialiste du dev web ni de javascript.
Ce qui est marrant avec Ajax, c'est qu'on a pas forcément besoin d'utiliser XML comme format de réponse. JSON est pas mal non plus, plus léger et plus facile a utiliser à mon gout. En fait n'importe quoi peut techniquement convenir bien qu'il soit largement préférable d'utiliser un format structurer comme XML ou JSON.
