ASM wrote:
> Ça alors !
> je n'ai aucun autre post de Thief13 si ce n'est celui du 12/08 ... ?!
> (et même pas : il a expiré sur mon serveur)

Le post auquel je répondais hier n'est plus disponible sur le serveur
que j'utilise non plus (news.free.fr). Toujours disponible dans le cache
Google par contre :
<http://groups.google.com/group/fr.comp.lang.javascript/msg/7ff092d3fefb4e96>
J'aurais tendance à devenir amer...

Mickaël Wolff wrote:
>> A ma connaissance onClick existe dans toutes les versions de HTML 4 et
>> XHTML 1.0 ou 1.1 !
>
> Je ne vois pas de référence à onClick, mais plutôt onclick


Ce n'est pas une remarque anodine d'ailleurs... J'ai pris l'habitude
d'écrire onClick, onChange etc... avec cette casse à l'époque où j'ai
appris JavaScript. Je ne me suis jamais bien posé de questions sur la
chose... Je crois cependant que la casse de l'attribut aurait toute son
importance en XHTML...

Si quelqu'un a plus d'infos sur le sujet... (pas trop le temps en ce moment)

Mickaël Wolff wrote:
>> A ma connaissance onClick existe dans toutes les versions de HTML 4 et
>> XHTML 1.0 ou 1.1 !
>
> Je ne vois pas de référence à onClick, mais plutôt onclick


Ce n'est pas une remarque anodine d'ailleurs... J'ai pris l'habitude
d'écrire onClick, onChange etc... avec cette casse à l'époque où j'ai
appris JavaScript. Je ne me suis jamais bien posé de questions sur la
chose... Je crois cependant que la casse de l'attribut aurait toute son
importance en XHTML...

Si quelqu'un a plus d'infos sur le sujet... (pas trop le temps en ce moment)

ASM a écrit :
(snip)
> Ben tant mieux, ça me semble encore un bon exemple de méthodes utilisées
> mais mal digérées et qui va dans mon idée que les biblis JS ne devraient
> n'être que confidentielles (ou payantes et à ne pas livrer sans
> pré-requis).

Amis extremistes, bonjour...

ASM a écrit :
(snip)
> Ben tant mieux, ça me semble encore un bon exemple de méthodes utilisées
> mais mal digérées et qui va dans mon idée que les biblis JS ne devraient
> n'être que confidentielles (ou payantes et à ne pas livrer sans
> pré-requis).

Amis extremistes, bonjour...

En réponse à Bruno Desthuilliers qui écrivit, en date du : 29/08/07
18:35, le message suivant :
> ASM a écrit :
> (snip)
>> Ben tant mieux, ça me semble encore un bon exemple de méthodes
>> utilisées mais mal digérées et qui va dans mon idée que les biblis JS
>> ne devraient n'être que confidentielles (ou payantes et à ne pas
>> livrer sans pré-requis).
>
> Amis extremistes, bonjour...

:-)

mais néanmoins ...

En réponse à Bruno Desthuilliers qui écrivit, en date du : 29/08/07
18:35, le message suivant :
> ASM a écrit :
> (snip)
>> Ben tant mieux, ça me semble encore un bon exemple de méthodes
>> utilisées mais mal digérées et qui va dans mon idée que les biblis JS
>> ne devraient n'être que confidentielles (ou payantes et à ne pas
>> livrer sans pré-requis).
>
> Amis extremistes, bonjour...

:-)

mais néanmoins ...

Le Wed, 29 Aug 2007 17:01:25 +0200, Pierre Goiffon a écrit:
> Ce n'est pas une remarque anodine d'ailleurs... J'ai pris l'habitude
> d'écrire onClick, onChange etc... avec cette casse à l'époque où j'ai
> appris JavaScript. Je ne me suis jamais bien posé de questions sur la
> chose... Je crois cependant que la casse de l'attribut aurait toute son
> importance en XHTML...

Les noms d'attributs, comme les noms de balises, ont le même comportement
qu'en XML (normal), à savoir qu'ils sont sensibles à la casse. Et que la
convention fait qu'on a pris les minuscules.

Donc, en XHTML, onclick plutôt que onClick, car sinon ca ne valide pas
(même si les navigateurs vont probablement accepter les deux, sauf si on
est en strict et bien en mode XML et pas tag soup).

De toute façon c'est mal de mélanger présentation et logique, donc mieux
vaut un code javascript à part qui parse le DOM pour attacher les
gestionnaires d'événement, et avoir donc son (x)HTML sans aucun code
javascript...

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Wed, 29 Aug 2007 17:01:25 +0200, Pierre Goiffon a écrit:
> Ce n'est pas une remarque anodine d'ailleurs... J'ai pris l'habitude
> d'écrire onClick, onChange etc... avec cette casse à l'époque où j'ai
> appris JavaScript. Je ne me suis jamais bien posé de questions sur la
> chose... Je crois cependant que la casse de l'attribut aurait toute son
> importance en XHTML...

Les noms d'attributs, comme les noms de balises, ont le même comportement
qu'en XML (normal), à savoir qu'ils sont sensibles à la casse. Et que la
convention fait qu'on a pris les minuscules.

Donc, en XHTML, onclick plutôt que onClick, car sinon ca ne valide pas
(même si les navigateurs vont probablement accepter les deux, sauf si on
est en strict et bien en mode XML et pas tag soup).

De toute façon c'est mal de mélanger présentation et logique, donc mieux
vaut un code javascript à part qui parse le DOM pour attacher les
gestionnaires d'événement, et avoir donc son (x)HTML sans aucun code
javascript...

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek a écrit :
(snip)

> De toute façon c'est mal de mélanger présentation et logique, donc 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).

!-)

Patrick Mevzek a écrit :
(snip)

> De toute façon c'est mal de mélanger présentation et logique, donc 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).

!-)

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 :

- ça m'énerve qu'on fasse charger 21 à 65 ko de bibli pour n'en utiliser
que l'équivalent de 1 ou 2 ko
- je continue à penser que ça n'évite pas les dérives et mésemplois du
code html/css/script-client/script-serveur,
... 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)

Pour résumer, les biblis c'est :
- lourd
- incompréhensible
- à n'utiliser qu'en *parfaite* connaissance

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.

..

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 :

- ça m'énerve qu'on fasse charger 21 à 65 ko de bibli pour n'en utiliser
que l'équivalent de 1 ou 2 ko
- je continue à penser que ça n'évite pas les dérives et mésemplois du
code html/css/script-client/script-serveur,
... 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)

Pour résumer, les biblis c'est :
- lourd
- incompréhensible
- à n'utiliser qu'en *parfaite* connaissance

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.

..

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à !-)

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à !-)

En réponse à Bruno Desthuilliers qui écrivit, en date du : 31/08/07
13:22, le message suivant :
> ASM a écrit :
>>
>> 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.

Ha ! tu es donc d'accord !
La méconnaissance basique entraine à n'importe quoi !
(ici l'utilisation de la bibli ferait oublier ce qui tourne autour)

> En tout état de cause, mettre ce problème sur le dos de jQuery relève de
> la plus parfaite mauvaise foi.

Ça se voit tant que ça ?

> Vilain troll, và !-)

Ben ...
1) c'est sur un site d'info sur jQuery donc ... c'est sa fôte.
2) on a la mauvaise foi qu'on peut, qu'on veut.

:-)

3) en fait il faudrait prendre cet exemple comme un exemple de manip de
la bibli dans un certain but sans se poser la question de l'intéret
de ce but.
4) Le néophyte, malheureusement, pourra penser que ce but est idéal :-(
5) Je n'ai pas vu de mise en garde pour celui-ci.

En réponse à Bruno Desthuilliers qui écrivit, en date du : 31/08/07
13:22, le message suivant :
> ASM a écrit :
>>
>> 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.

Ha ! tu es donc d'accord !
La méconnaissance basique entraine à n'importe quoi !
(ici l'utilisation de la bibli ferait oublier ce qui tourne autour)

> En tout état de cause, mettre ce problème sur le dos de jQuery relève de
> la plus parfaite mauvaise foi.

Ça se voit tant que ça ?

> Vilain troll, và !-)

Ben ...
1) c'est sur un site d'info sur jQuery donc ... c'est sa fôte.
2) on a la mauvaise foi qu'on peut, qu'on veut.

:-)

3) en fait il faudrait prendre cet exemple comme un exemple de manip de
la bibli dans un certain but sans se poser la question de l'intéret
de ce but.
4) Le néophyte, malheureusement, pourra penser que ce but est idéal :-(
5) Je n'ai pas vu de mise en garde pour celui-ci.

ASM a écrit :
> En réponse à Bruno Desthuilliers qui écrivit, en date du : 31/08/07
> 13:22, le message suivant :
>> ASM a écrit :
>>>
>>> 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.
>
> Ha ! tu es donc d'accord !

Avec quoi ? Avec le fait que cet exemple n'est pas nécessairement à
suivre ? Evidemment oui. Avec le fait que c'est "induit par
l'utilisation de jQuery" ? Evidemment non. Parce que le problème n'est
lié ni à jQuery ni à une quelconque bibliothèque équivalente.

> La méconnaissance basique entraine à n'importe quoi !

Certes. De même que le manque de neurones. Je ne vois pas le rapport
avec la choucroute.

>> En tout état de cause, mettre ce problème sur le dos de jQuery relève
>> de la plus parfaite mauvaise foi.
>
> Ça se voit tant que ça ?

A ton avis ?

>> Vilain troll, và !-)
>
> Ben ...
> 1) c'est sur un site d'info sur jQuery donc ... c'est sa fôte.

Facile. N'importe qui peut poster n'importe quoi sur n'importe quel
sujet. A ce jeu là, vu le niveau moyen des tutoriels sur le langage C et
l'ineptie des pratiques recommendées sur certains, je pourrais conclure
que le C est un mauvais langage et qu'il faut l'interdire.

> 2) on a la mauvaise foi qu'on peut, qu'on veut.
>
> :-)

Ok, c'est marrant. Deux minutes. Trois minutes éventuellement. Quatre
minutes à la limite. Allez, cinq minutes, parce que je suis gentil.
Disons six minute au maximum, donc.

> 3) en fait il faudrait prendre cet exemple comme un exemple de manip de
> la bibli dans un certain but sans se poser la question de l'intéret
> de ce but.
> 4) Le néophyte, malheureusement, pourra penser que ce but est idéal :-(
> 5) Je n'ai pas vu de mise en garde pour celui-ci.

Tu es en droit de critiquer ce site, ou du moins cette page du site.
Pour ce que ça vaut, ladite page propose un formulaire pour soumettre un
commentaire, je m'étonne donc que tu n'en ai pas déjà poster un pour
signaler le problème. Ce serait AMHA plus constructif que de faire
étalage de mauvaise foi ici !-)

En tout état de cause, ça n'a aucun rapport avec tant la qualité que
l'utilité d'une bibliothèque comme jQuery, et l'argument est donc
rejeté. Autre chose ?-)


Allez, va, mon fils, et repend-toi. Heu, repent-toi, veuillé-je dire !-)

ASM a écrit :
> En réponse à Bruno Desthuilliers qui écrivit, en date du : 31/08/07
> 13:22, le message suivant :
>> ASM a écrit :
>>>
>>> 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.
>
> Ha ! tu es donc d'accord !

Avec quoi ? Avec le fait que cet exemple n'est pas nécessairement à
suivre ? Evidemment oui. Avec le fait que c'est "induit par
l'utilisation de jQuery" ? Evidemment non. Parce que le problème n'est
lié ni à jQuery ni à une quelconque bibliothèque équivalente.

> La méconnaissance basique entraine à n'importe quoi !

Certes. De même que le manque de neurones. Je ne vois pas le rapport
avec la choucroute.

>> En tout état de cause, mettre ce problème sur le dos de jQuery relève
>> de la plus parfaite mauvaise foi.
>
> Ça se voit tant que ça ?

A ton avis ?

>> Vilain troll, và !-)
>
> Ben ...
> 1) c'est sur un site d'info sur jQuery donc ... c'est sa fôte.

Facile. N'importe qui peut poster n'importe quoi sur n'importe quel
sujet. A ce jeu là, vu le niveau moyen des tutoriels sur le langage C et
l'ineptie des pratiques recommendées sur certains, je pourrais conclure
que le C est un mauvais langage et qu'il faut l'interdire.

> 2) on a la mauvaise foi qu'on peut, qu'on veut.
>
> :-)

Ok, c'est marrant. Deux minutes. Trois minutes éventuellement. Quatre
minutes à la limite. Allez, cinq minutes, parce que je suis gentil.
Disons six minute au maximum, donc.

> 3) en fait il faudrait prendre cet exemple comme un exemple de manip de
> la bibli dans un certain but sans se poser la question de l'intéret
> de ce but.
> 4) Le néophyte, malheureusement, pourra penser que ce but est idéal :-(
> 5) Je n'ai pas vu de mise en garde pour celui-ci.

Tu es en droit de critiquer ce site, ou du moins cette page du site.
Pour ce que ça vaut, ladite page propose un formulaire pour soumettre un
commentaire, je m'étonne donc que tu n'en ai pas déjà poster un pour
signaler le problème. Ce serait AMHA plus constructif que de faire
étalage de mauvaise foi ici !-)

En tout état de cause, ça n'a aucun rapport avec tant la qualité que
l'utilité d'une bibliothèque comme jQuery, et l'argument est donc
rejeté. Autre chose ?-)


Allez, va, mon fils, et repend-toi. Heu, repent-toi, veuillé-je dire !-)

Laurent vilday a écrit :
> ASM a écrit :
>
(snip)
>> - je continue à penser que ça n'évite pas les dérives et mésemplois du
>> code html/css/script-client/script-serveur,
>
>
> Si peu. Dernièrement j'ai vu un truc à peu près comme ça :
>
> <div style="display:inline" id="link_23">Check my realisations</div>
> <script>
> $('link23').click(function() { window.location = itemGetter(23); };
> </script>

mmmouaaarffffffffffffff

(sniff)

Alors là, franchement, c'est un *grand* WTF !


>> - incompréhensible
>
>
> Meuh non lol.
>
> librairie PlotKit, Layout.js, ligne 344 à 350
>
> var collapse = PlotKit.Base.collapse;
> var map = PlotKit.Base.map;
> var getter = MochiKit.Base.itemgetter;
> var items = PlotKit.Base.items;
>
> var xvalues = map(parseFloat, map(getter(0), collapse(map(getter(1),
> items(this.datasets)))));
>
> Ou tu vois du compliqué toi ?

C'est pas compliqué, c'est LISPesque. Hein ? C'est pareil ? Mais non
c'est pas pareil !-)

> Petite explication de ce que ça fait. En gros ça transforme un tableau
> comme ceci :
>
> var datasets = [
> [1,23], [2,10], [3,40], [10,50],
> [0,17], [1,40], [2,20], [3,40], [4,10]
> ];
>
> en ceci : [0,1,2,3,4,5,6,7,8,9,10]
>
> Je me rend bien compte qu'une bête boucle " for " c'était pas assez
> hype, map(itemgetter()) ca le fait tellement plus

Plus sérieusement, là, c'est plus une question d'habitude. Un
programmeur habitué aux langages fonctionnels comprendra plus facilement
un truc à base de map/filter/reduce et autres opérations
'ensemblistes' que la version impérative à base de boucles. Le cas que
tu cites est limite pathologique (soit c'est un lispeur, soit le gars
vient de découvrir l'approche fonctionnelle), mais bien utilisé, c'est
AMHA souvent plus lisible que les idiomes purements impératifs.

(snip)

>> 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)
>
>
> Tant pis, je vais tenir le rôle de l'idiot alors. Je comptais sur toi
> pourtant :p
>
> Les librairies *sont* à bannir car il n'existe que 2 cas de figure
>
> 1) vous connaissez javascript et par conséquent vous avez vos propres
> librairies adaptées à vos besoins et donc pas besoin de YUI, jQuery,
> Prototype et autre Ext
>
> 2) vous ne connaissez pas javascript et par conséquent il est recommandé
> de ne pas approcher ces librairies qui ne feront que vous embrouiller.
> On fait du javascript, pas du javascript à la ruby comme Prototype fait
> par exemple.
>
> Moralité, pas de librairies ! D'autant qu'il suffit de mettre le nez 2
> minutes dans n'importe lesquelles de ces librairies pour se demander si
> c'est un humain qu'à réellement pondu une telle sal... oops pardon une
> telle chose.

Amis extremistes, bonsoir.

Plus une bibliothèque (parlons français) est utilisée, plus il y a de
chances qu'elle soit débuggée (en tous cas pour les biblios open
source). En ce qui me concerne, je ne vois pas l'intérêt de réinventer
la roue carrée quand d'autres se sont déjà donné du mal à l'arrondir.

Accessoirement, avec ce genre de raisonnement, on ne développe qu'en
langage machine ou avec son propre langage et son propre
compilo/interpréteur (rayer la mention inutile).

Par ailleurs, dans un contexte professionnel, on développe rarement
"from scratch", et la plupart des frameworks/CMS/whatever existants
intègrent déjà une de ces bibliothèques. Dans ce cas, il serait inepte
de l'ignorer.

Bref, le purisme, c'est bien joli, mais c'est pas ça qui fait bouillir
la marmite. Ca ne veut pas dire qu'il faille mettre des décos de Noël
partout juste parce qu'on les a sous la main, ni qu'il faille se
contenter d'utiliser l'existant sans chercher à comprendre (et
éventuellement à contribuer), mais honnêtement, si je développe une
extension pour un CMS qui embarque déjà jQuery (au hasard), je ne voit
aucune raison de coder mes appels XHR à la mano (ce que je sais faire
aussi) quand je peux avoir le même résultat en une ligne de code.

Laurent vilday a écrit :
> ASM a écrit :
>
(snip)
>> - je continue à penser que ça n'évite pas les dérives et mésemplois du
>> code html/css/script-client/script-serveur,
>
>
> Si peu. Dernièrement j'ai vu un truc à peu près comme ça :
>
> <div style="display:inline" id="link_23">Check my realisations</div>
> <script>
> $('link23').click(function() { window.location = itemGetter(23); };
> </script>

mmmouaaarffffffffffffff

(sniff)

Alors là, franchement, c'est un *grand* WTF !


>> - incompréhensible
>
>
> Meuh non lol.
>
> librairie PlotKit, Layout.js, ligne 344 à 350
>
> var collapse = PlotKit.Base.collapse;
> var map = PlotKit.Base.map;
> var getter = MochiKit.Base.itemgetter;
> var items = PlotKit.Base.items;
>
> var xvalues = map(parseFloat, map(getter(0), collapse(map(getter(1),
> items(this.datasets)))));
>
> Ou tu vois du compliqué toi ?

C'est pas compliqué, c'est LISPesque. Hein ? C'est pareil ? Mais non
c'est pas pareil !-)

> Petite explication de ce que ça fait. En gros ça transforme un tableau
> comme ceci :
>
> var datasets = [
> [1,23], [2,10], [3,40], [10,50],
> [0,17], [1,40], [2,20], [3,40], [4,10]
> ];
>
> en ceci : [0,1,2,3,4,5,6,7,8,9,10]
>
> Je me rend bien compte qu'une bête boucle " for " c'était pas assez
> hype, map(itemgetter()) ca le fait tellement plus

Plus sérieusement, là, c'est plus une question d'habitude. Un
programmeur habitué aux langages fonctionnels comprendra plus facilement
un truc à base de map/filter/reduce et autres opérations
'ensemblistes' que la version impérative à base de boucles. Le cas que
tu cites est limite pathologique (soit c'est un lispeur, soit le gars
vient de découvrir l'approche fonctionnelle), mais bien utilisé, c'est
AMHA souvent plus lisible que les idiomes purements impératifs.

(snip)

>> 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)
>
>
> Tant pis, je vais tenir le rôle de l'idiot alors. Je comptais sur toi
> pourtant :p
>
> Les librairies *sont* à bannir car il n'existe que 2 cas de figure
>
> 1) vous connaissez javascript et par conséquent vous avez vos propres
> librairies adaptées à vos besoins et donc pas besoin de YUI, jQuery,
> Prototype et autre Ext
>
> 2) vous ne connaissez pas javascript et par conséquent il est recommandé
> de ne pas approcher ces librairies qui ne feront que vous embrouiller.
> On fait du javascript, pas du javascript à la ruby comme Prototype fait
> par exemple.
>
> Moralité, pas de librairies ! D'autant qu'il suffit de mettre le nez 2
> minutes dans n'importe lesquelles de ces librairies pour se demander si
> c'est un humain qu'à réellement pondu une telle sal... oops pardon une
> telle chose.

Amis extremistes, bonsoir.

Plus une bibliothèque (parlons français) est utilisée, plus il y a de
chances qu'elle soit débuggée (en tous cas pour les biblios open
source). En ce qui me concerne, je ne vois pas l'intérêt de réinventer
la roue carrée quand d'autres se sont déjà donné du mal à l'arrondir.

Accessoirement, avec ce genre de raisonnement, on ne développe qu'en
langage machine ou avec son propre langage et son propre
compilo/interpréteur (rayer la mention inutile).

Par ailleurs, dans un contexte professionnel, on développe rarement
"from scratch", et la plupart des frameworks/CMS/whatever existants
intègrent déjà une de ces bibliothèques. Dans ce cas, il serait inepte
de l'ignorer.

Bref, le purisme, c'est bien joli, mais c'est pas ça qui fait bouillir
la marmite. Ca ne veut pas dire qu'il faille mettre des décos de Noël
partout juste parce qu'on les a sous la main, ni qu'il faille se
contenter d'utiliser l'existant sans chercher à comprendre (et
éventuellement à contribuer), mais honnêtement, si je développe une
extension pour un CMS qui embarque déjà jQuery (au hasard), je ne voit
aucune raison de coder mes appels XHR à la mano (ce que je sais faire
aussi) quand je peux avoir le même résultat en une ligne de code.

ASM a écrit :
> En réponse à Bruno Desthuilliers qui écrivit, en date du : 30/08/07
>> Tâche que certaines bibliothèques tant décriées par notre ami ASM
>> facilite grandement (jQuery, entre autres
>
> .... je suis désolé de maintenir ma position :

Ehehe, soit pas désolé Stéphane, assumes

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

Si peu. Dernièrement j'ai vu un truc à peu près comme ça :

<div style="display:inline" id="link_23">Check my realisations</div>
<script>
$('link23').click(function() { window.location = itemGetter(23); };
</script>

J'avoue ne toujours pas saisir l'intérêt, mais bon le mec était super
hype, ça clignotait de partout, en n'utilisant que la bagatelle de 3 ou
4 librairies sur chaque page :p

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

Humm, quand j'ai un client qui me balance 20 images de 500k sur la même
page, j'ai tendance à ignorer la problématique du "la librairie est trop
grosse". D'autant qu'ils existent de nombreuses méthodes pour réduire la
taille.

La plus simple c'est évidemment mod_gzip.

Suivi je pense par un peu d'expression régulière sur du code javascript
strict (pas de ; manquants, pas de {} manquants, etc.
<http://www.jslint.com/>) - si ça intéresse qqun je peux fournir ma
méthode PHP qui réduit tout mes javascripts, suffit de demander -

Et pour finir si vraiment c'est pas assez mais j'en doute, au pire il
reste les packers, YUI compressor et autre dojo shrink safe
<http://ajaxian.com/archives/compressorrater-compare-the-squeeze>

> - incompréhensible

Meuh non lol.

librairie PlotKit, Layout.js, ligne 344 à 350

var collapse = PlotKit.Base.collapse;
var map = PlotKit.Base.map;
var getter = MochiKit.Base.itemgetter;
var items = PlotKit.Base.items;

var xvalues = map(parseFloat, map(getter(0), collapse(map(getter(1),
items(this.datasets)))));

Ou tu vois du compliqué toi ?

Petite explication de ce que ça fait. En gros ça transforme un tableau
comme ceci :

var datasets = [
[1,23], [2,10], [3,40], [10,50],
[0,17], [1,40], [2,20], [3,40], [4,10]
];

en ceci : [0,1,2,3,4,5,6,7,8,9,10]

Je me rend bien compte qu'une bête boucle " for " c'était pas assez
hype, map(itemgetter()) ca le fait tellement plus

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

Si seulement

> 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)

Tant pis, je vais tenir le rôle de l'idiot alors. Je comptais sur toi
pourtant :p

Les librairies *sont* à bannir car il n'existe que 2 cas de figure

1) vous connaissez javascript et par conséquent vous avez vos propres
librairies adaptées à vos besoins et donc pas besoin de YUI, jQuery,
Prototype et autre Ext

2) vous ne connaissez pas javascript et par conséquent il est recommandé
de ne pas approcher ces librairies qui ne feront que vous embrouiller.
On fait du javascript, pas du javascript à la ruby comme Prototype fait
par exemple.

Moralité, pas de librairies ! D'autant qu'il suffit de mettre le nez 2
minutes dans n'importe lesquelles de ces librairies pour se demander si
c'est un humain qu'à réellement pondu une telle sal... oops pardon une
telle chose.

--
laurent