PHWinfo - Afficher un message

31/08/2007, 13h22

ASM a écrit :
> En réponse à Bruno Desthuilliers qui écrivit, en date du : 30/08/07
> 14:14, le message suivant :
>> Patrick Mevzek a écrit :
>>
>>> mieux
>>> vaut un code javascript à part qui parse le DOM pour attacher les
>>> gestionnaires d'événement,
>>
>> Tâche que certaines bibliothèques tant décriées par notre ami ASM
>> facilite grandement (jQuery, entre autres, rend cette opération tout à
>> fait triviale).
>>
>> !-)
>
> ... je suis désolé de maintenir ma position :

J'en suis désolé aussi !-)

> - ça m'énerve qu'on fasse charger 21 à 65 ko de bibli pour n'en utiliser
> que l'équivalent de 1 ou 2 ko

On a déjà eu ce débat. Pour quoi que ce soit de non-trivial, ce coût est
AMHA totalement justifié. Evidemment, si c'est pour faire quelque chose
qui se fait (sans pb de portabilité) en deux lignes de code sans la
biblio, c'est débile - mais à ce stade, il n'y a plus guère de thérapie
possible !-)

> - je continue à penser que ça n'évite pas les dérives et mésemplois du
> code html/css/script-client/script-serveur,

Non, et alors ? Le mauvais emploi d'un outil ne rends pas l'outil
mauvais. Tu veux interdire les marteaux sous prétexte que certains s'en
servent pour taper sur la tête de leurs contemporains ?

> ... le plus souvent par méconnaissance de principes de base
> - ces biblis ne sont pas exemptes de pièges
> pièges qui pourront être difficilement contournables
> (surtout par un néophyte)

C'est tout aussi vrai de Javascript sans ces bibliothèques, donc ça
n'apporte rien.

> Pour résumer, les biblis c'est :
> - lourd

On a déjà eu ce débat.

> - incompréhensible

Pour qui ?-)

(Non, ne réponds pas, c'était juste une basse provocation...)

> - à n'utiliser qu'en *parfaite* connaissance

Et le html, c'est à n'utiliser qu'en "parfaite" connaissance ? Et
javascript "à la papa" ? Et le PHP ?

> Néanmoins je ne peux que reconnaitre leur utilité dans le développement
> d'un site *bien pensé*.
> (je suis idiot mais pas au point de dire qu'elles sont à bannir)
>
> Tiens : un exemple de truc tordu induit par l'utilisation de jQuery
> "Afficher la page brute si le javascript est désactivé"
> http://www.jquery.info/spip.php?article28
> dont l'astuce (code #2) consiste pour chaque lien ajaquessé à devoir
> fabriquer préalablement 2 fichiers pour un résultat identique.

Ce n'est pas "un truc tordu induit par l'utilisation de jQuery", c'est
juste un manque de réflexion sur un problème posé par l'utilisation d'un
objet XMLHttpRequest pour charger un fragment HTML.

La solution canonique consiste bien sûr à utiliser js pour ajouter un
paramètre (ie : fragment=1) à l'url, et à construire sa vue (php,
template, etc...) de façon à ce qu'elle renvoie soit une page complète,
soit seulement le fragment.

En tout état de cause, mettre ce problème sur le dos de jQuery relève de
la plus parfaite mauvaise foi. Vilain troll, và !-)

31/08/2007, 13h22	#39
Bruno Desthuilliers Messages: n/a Hébergeur:	Re: divers problemes Ajax ASM a écrit : > En réponse à Bruno Desthuilliers qui écrivit, en date du : 30/08/07 > 14:14, le message suivant : >> Patrick Mevzek a écrit : >> >>> mieux >>> vaut un code javascript à part qui parse le DOM pour attacher les >>> gestionnaires d'événement, >> >> Tâche que certaines bibliothèques tant décriées par notre ami ASM >> facilite grandement (jQuery, entre autres, rend cette opération tout à >> fait triviale). >> >> !-) > > ... je suis désolé de maintenir ma position : J'en suis désolé aussi !-) > - ça m'énerve qu'on fasse charger 21 à 65 ko de bibli pour n'en utiliser > que l'équivalent de 1 ou 2 ko On a déjà eu ce débat. Pour quoi que ce soit de non-trivial, ce coût est AMHA totalement justifié. Evidemment, si c'est pour faire quelque chose qui se fait (sans pb de portabilité) en deux lignes de code sans la biblio, c'est débile - mais à ce stade, il n'y a plus guère de thérapie possible !-) > - je continue à penser que ça n'évite pas les dérives et mésemplois du > code html/css/script-client/script-serveur, Non, et alors ? Le mauvais emploi d'un outil ne rends pas l'outil mauvais. Tu veux interdire les marteaux sous prétexte que certains s'en servent pour taper sur la tête de leurs contemporains ? > ... le plus souvent par méconnaissance de principes de base > - ces biblis ne sont pas exemptes de pièges > pièges qui pourront être difficilement contournables > (surtout par un néophyte) C'est tout aussi vrai de Javascript sans ces bibliothèques, donc ça n'apporte rien. > Pour résumer, les biblis c'est : > - lourd On a déjà eu ce débat. > - incompréhensible Pour qui ?-) (Non, ne réponds pas, c'était juste une basse provocation...) > - à n'utiliser qu'en parfaite connaissance Et le html, c'est à n'utiliser qu'en "parfaite" connaissance ? Et javascript "à la papa" ? Et le PHP ? > Néanmoins je ne peux que reconnaitre leur utilité dans le développement > d'un site bien pensé. > (je suis idiot mais pas au point de dire qu'elles sont à bannir) > > Tiens : un exemple de truc tordu induit par l'utilisation de jQuery > "Afficher la page brute si le javascript est désactivé" > http://www.jquery.info/spip.php?article28 > dont l'astuce (code #2) consiste pour chaque lien ajaquessé à devoir > fabriquer préalablement 2 fichiers pour un résultat identique. Ce n'est pas "un truc tordu induit par l'utilisation de jQuery", c'est juste un manque de réflexion sur un problème posé par l'utilisation d'un objet XMLHttpRequest pour charger un fragment HTML. La solution canonique consiste bien sûr à utiliser js pour ajouter un paramètre (ie : fragment=1) à l'url, et à construire sa vue (php, template, etc...) de façon à ce qu'elle renvoie soit une page complète, soit seulement le fragment. En tout état de cause, mettre ce problème sur le dos de jQuery relève de la plus parfaite mauvaise foi. Vilain troll, và !-)