C'est l'impression que j'avais eu aussi quand j'avais testé, mais là les quelques exemples d'Oxman sont plutôt encourageant de ce côté !


Sephi-Chan

Citation :$. est déjà un peu spécial en soit, admettons que ça soit une convention de codage.
C'est déjà pas très propre comparé à un new Request.

Je ne suis pas d'accord, $. n'est pas une notation spéciale, c'est la même que prototype pour remplacer le getById, ce qui suit la logique de passer un sélecteur DOM en argument.

Citation :Tu sais de plus précisément ce que tu fais, url:, l'url à appeler, onComplete: sur la complétion on appel la fonction.
Continuons cet exemple pour bien comprendre le problème (je me base toujours des docs, je peux faire des erreurs).

Comment je fais si je veux appeler une fonction lors d'un échec de l'appel avec jQuery ?
Je viens de voir la doc, je ne vois pas où c'est indiqué comment faire, assurément on peut, mais là je ne sais pas comment.

C'est faux
La fonction $.ajax accepte en paramètre success et error, de même qu'il existe les deux fonctions .ajaxComplete et .ajaxError

Quant aux appels objet de mootools, je préfère la fonction de jQuery, le principe est basé sur les closures javascript ( http://www.jibbering.com/faq/faq_notes/closures.html ) ce qui permet une forte interaction entre les variables et les plugins ( http://www.learningjquery.com/2007/10/a-...nt-pattern ) et aussi d'enchainer les fonctions.

Dans le lien sur les closures, on peut y apprendre, qu'elles ont été implémentés afin de dynamiser le système Objet et l'étendre.

On peut aussi rappeler que jQuery est plus rapide lors des sélections de DOM usuelles ( http://www.anthor.net/fr/slickspeed-tests.html )

J'ai bien dit $. et non $
$() est un sélécteur oui.
$. dans le cas de jQuery est équivalent de new Patati, par exemple $.getJSON = new Request.JSON

Mootools en 1.1 était déjà pas mal clair et logique au niveau de sa structure, depuis la 1.2 on a encore fait un gros bond en avant, il reste encore du boulot, mais c'est déjà clairement mieux que jQuery à ce niveau.

Concernant les plugins, peut-être, mais du point de vue utilisateur j'en doute, car les modules Mootools s'intègrent si bien que j'ai à chaque fois l'impression qu'en fait c'est Mootools. Point de vue programmeur, je n'en sais rien, je n'en ai jamais codé.

Je peux savoir pourquoi j'ai l'impression que tu es de mauvaise foi Anthor ? Tu me dis que c'est faux en coupant volontairement un bout de ce que j'ai écrit, le bout coupé est le suivant :

Citation :Edit :
Je viens de trouver cette information :
$("#msg").ajaxError(function(event, request, settings){
$(this).append("<li>Error requesting page " + settings.url + "</li>");
});
Visiblement la définition d'erreur ne se fait pas de la même façon, encore un peu abscons tout ça.

Je dis donc bien qu'après avoir analysé plus en détail la documentation, j'ai trouvé que c'était possible de le faire, mais de manière abscons.

Je peux sortir encore plusieurs exemples du type new Request.JSON et $.getJSON si vous voulez.

Concernant la rapidité, ça n'est clairement pas un critère, d'autant plus qu'il est amusant de voir que jQuery sort gagnant de ce test en laissant les choix par défaut, mais que Mootools sort gagnant du test si on décide de faire le test sur les 40 sélécteurs (tout ceux possible dans le test).

Concernant les closures, je ne commente pas pour le moment, il faut que je regarde précisément tout ça.

Les 15 sélecteurs sont par défaut des sélecteurs qui sont utilisés dans 90% des cas. Qu'une librairie aille plus vite sur 10% de sélecteur ne veut pas forcement dire qu'à l'utilisation quotidienne cette libraire sera plus rapide.

Il n'y a aucune mauvaise foi dans ce que j'explique. Je te faisais simplement remarquer que $.getJSON étant un alias simplifié de Ajax, il est normal qu'il ne dispse pas de toutes les options, mais que ces options existent belles et biens. Et elle se trouve dans la documentation.

De plus je ne dis pas que l'une ou l'autre est mieux, je sais que personnellement, et les autres développeurs avec qui je travaille, nous travaillons tous sous jQuery après avoir écrit beaucoup de scripts sur la majorité des librairies, et aussi en JS pur.

La gestion des plugins nous permet des développements unifiés et nous travaillons bien plus vite avec jQuery. Ce n'est que mon avis.

Pour le moment je n'ai encore que peu regardé les documentations que tu m'a donné.

Mais pour le moment, dans ce que j'ai vu, en fait ce sont deux écoles de styles (où des pratiques plutôt) qui "s'affronte".

D'un coté tu as ton objet/élément que nous nommerons Bouh dans notre exemple, qui est défini (de manière générale) par $('Bouh').

Dans une des pratiques, les plugins créent des nouvelles méthodes à cet objet, par exemple :
objet.accordion();
Dans l'autre des pratiques on créer un nouvel objet avec l'objet que nous avons :
new Accordion(objet);

Il s'avère que je suis un peu décontenancé en fait, que l'écriture .accordion me convient plus, et me semble plus adaptée.
Mais de ce fait, je me demande quels sont les problèmes de cette méthode, quelle est vraiment la logique de l'une et de l'autre des méthodes, et pourquoi on utilise si souvent l'autre méthode "new Class(objet)" habituellement, tant l'autre me semble (sans approfondir) plus logique.

Je rappelle que je n'ai pas encore creusé, je vais creuser un peu plus, mais ce qui semble sur, c'est que chacun dans sa méthode, Mootools semble mieux s'en sortir au niveau de la cohérence des arguments.

Globalement la grande différence c'est que dans mootools ou prototype tu as de multiples objets.

jQuery tu n'as qu'un objet dans lequel tu passes un objet DOM qui va être sélectionné en argument, puis tu enchaines les différentes fonctions qui héritent toutes de l'objet principal.

Chaque fonction étant une extension de l'objet jQuery, aliasé par un $, de ce fait chaque fonction de jQuery sont aussi des plugins.

Oui mais pourquoi partout on fait new Bidule(objet) plutot que objet.bidule()
C'est bien qu'au final il est plus propre et plus adapté de faire new Bidule(objet) non ?

Parce que contrairement aux objets, les fonctions des closures peuvent avoir accès à toutes les variables, et ne former qu'un objet homogène.
Une variable crée dans une fonction closurée existe encore une fois la fonction terminées.

Pour que tu comprennes, la closure en javascript c'est lorsque tu créé une fonction variable sans utiliser le mot clé var.

L'appel à la fonction PublicFunction() fonctionne tandis que la fonction PrivateFunction() retourne une erreur de variable non définie, et la fonction Objet ne fait rien.

Tu peux d'ors et déjà y voir un prémisse d'orienté objet avec une visiblité des méthodes.
Bon ok, l'exemple est simple, on en fait pas un plat, on appel que des fonctions, y'a pas vraiment d'objet la dedans !

Si on pousse le bouchon un peu plus loin :

J'ai ajouté des parenthèses à la fin de ma variable Objet, cela indique à Javascript d'exécuter directement après chargement ma fonction. Cela me permet de me retrouver avec un Objet qui contient 4 méthodes.

Je peux maintenant jouer avec mon objet et protéger des données et des méthodes


Après si tu as compris le début de principe, ça te permet de contourner les limitations de l'objet du langage Javascript pour utiliser des portées de méthodes, mais aussi de pouvoir utiliser des fonctions en callback qui s'exécute dans le contexte de ton objet. Et ce n'est que le principe de base.

Mais oui, mais ça ne semble pas propre d'avoir tous les objets mergés en un seul gros objet, peut-etre plus pratique, mais moins propre, je me gourre ou pas ?

Anthor, tu m'épates par ta maîtrise de Javascript. Ce genre de choses ne s'inventent pas (le second exemple, en particulier). Comment connaît tu ces choses ?


Sephi-Chan, on the cul…