Logo_jQuery

Des nouvelles de jQuery, épisode 44

flattr this!

En pleine période JSconf et de JQcon, voilà de l'annonce et de nouvelles choses qui se sont produites cette semaine dans le monde merveilleux de jQuery. (comment ça vous espériez que je dise bisounours ?)

Tout d'abord : jQuery 1.7 beta 1 est disponible ! jQuery Mobile RC 1 aussi !

Commençons par la 1.7 du core. Le changement le plus important se situe du côté de la gestion des évènements. A mon avis, ce changement nécessitera un billet séparé que j'ai le temps de tout étudier en profondeur. Dans les grandes lignes, les méthodes bind(), delegate(), live() et leurs opposées respectives unbind(), undelegate() et die() dégagent. Enfin elles deviennent obsolètes et même si maintenues ne doivent plus êtres utilisées. Elles sont remplacées par un duo simplifié de méthodes : on() et off(). Je reprends le tableau proposé par l'annonce officielle pour proposer des exemples de ce changement :

 

Old API	                                      New API
$(elems).bind(events, fn)	              $(elems).on(events, fn)
$(elems).bind(events, { mydata: 42 }, fn)     $(elems).on(events, { mydata: 42 }, fn)
$(elems).unbind(events, fn)	              $(elems).off(events, fn)
$(elems).delegate(events, selector, fn)	      $(elems).on(events, selector, fn)
$(elems).undelegate(events, selector, fn)     $(elems).off(events, selector, fn)
$(selector).live(events, fn)	              $(document).on(events, selector, fn)
$(selector).die(events, fn)	              $(document).off(events, selector, fn)

Reste à savoir si l'unification de bind() et live() ne va pas poser des soucis de performances. bind() qui est derrière les méthodes telles que click() obtenaient de bien meilleurs résultats que live() qui était littéralement un escargot. Une batterie de tests est nécessaire.

Pour le reste, c'est une compilation de petites nouveautés pratiques. La fonction removeAttr() peut maintenant supprimer plusieurs éléments. Exemple :

 

var div = $("<div id='a' alt='b' title='c' rel='d'></div>");
div.removeAttr( "id alt title rel" );

La fonction removeData(), comme pour removeAttr(), permet maintenant de supprimer plusieurs données en passant une chaîne de noms séparés par des espaces, ou via un tableau de noms. Dailleurs, il faut que je signale que, dans la documentation, il y a deux pages "clones" concernant removeData()...

Du côté des animations, une amélioration a été apportée permettant un esthétisme amélioré. L'arrêt prématuré d'une animation bloquait en l'état l'élément dans une taille qui n'était pas celle souhaitée. Ce souci est réglé.

Pour finir sur jQuery 1.7 beta 1, le support du HTML 5 a été amélioré et la gestion des évènements change et submit pour les formulaires sous IE 6, 7 et 8 a été amélioré. Vous pouvez consulter l'annonce officielle, contenant un changelog détaillé, et un billet très intéressant sur le blog d'Addy Osmani, l'un des contributeurs rappelons le.

Avant de passer à l'activité en générale, on va quand même faire un crochet sur l'annonce de jQuery Mobile RC 1. Etant donné qu'ils sont sur une phase de stabilisation du framework, peu de grosses nouveautés.

Ceci dit, ils en ont profité pour améliorer le widget "pliant" (collapsible) et l'accordéon. Au passage, ils ont ajouté un attribut data-content-theme. Je n'ai pas encore saisi la teneur de cet élément, désolé, je vous en reparlerai donc plus tard, quand j'aurai compris. Apparemment cela permet de changer une partie de l'apparence de l'accordéon en retirant les coins arrondis entre autres.

Les transitions et les barres d'outils pour iOS 5 ont été revus mais elles ont aussi été désactivées par défaut. Pour la simple et bonne raison que tant que cet OS n'est pas disponible en version définitive, ils préfèrent émettre des réserves sur la viabilité de cet élément sur cet OS.

Du côté du champ de recherche, l'icône d'illustration est désormais personnalisable. C'était le dernier qui manquait à l'appel. Pour l'anecdote, IE 6 et 7 ne pourront pas afficher cet icône, la technique de sprite utilisée n'étant tout simplement pas supportée par ces navigateurs. Décidément, ceux sont vraiment une calamité ceux-là.

Je compte vous en parler prochainement dans un billet à propos du maquettage d'applications jQuery Mobile : un ThemeRoller dédié est en préparation ! C'est Tyler Benzinger, un ingénieur de chez Adobe, qui s'y colle. Je vous propose une vidéo mise en ligne par Scott Jehl pour en avoir un aperçu.

Idem du côté du DownloadBuilder, je vous en parlais déjà la semaine dernière, cet outil permettra de charger une version personnalisée de jQuery Mobile adaptée à vos besoins.

Et pour finir, vu que beaucoup d'utilisateurs ont râlé (exemple), une documentation "classique" est en préparation, la documentation exemple n'étant apparemment pas suffisante.

Sortons des annonces pour passer aux forums. Un utilisateur s'est plaint (ce qui peut se comprendre), que les contrôles de formulaire que sont les checkboxes, les radios, les textfields, textareas, et autres ne soient pas encore personnalisables. Scott Gonzales a rappelé que cela fait partie de la roadmap pour la version 2.0.

Du côté des plugins, je vous propose MobiScroll, proposé originellement par LaFermeDuWeb. Un très bon Date-DateTime-Time-NimporteQuoi Picker. Construit selon les normes les plus récentes de construction de plugins, celui-ci permet comme sa catégorisation l'indique de saisir facilement une date, une heure, une date et une heure ou encore une combinaison d'images à la méthode machine à sous. Il reprend le style graphique des widgets équivalents sur nos OS mobiles tels qu'Android et iOS, sur lesquels il est aussi compatible.

Au passage, l'ami Gilles Felix de chez Novius-Labs a mis à jour son superbe plugin inputFileThumb. Celui-ci remplace agréablement le champ de fichier de vos formulaires. Je ne pouvais que transmettre l'info ;) Vous pouvez jouer avec aussi sur GitHub.

D'ailleurs en parlant de chargement de fichiers, TutorialZine a proposé un tutoriel très complet sur un chargeur de fichiers utilisant jQuery et HTML 5. Je ne peux là aussi que vous suggérer d'y jeter un oeil.

Le site Speckyboy a par ailleurs proposé une liste de 40 plugins récents pour jQuery. Pour info.

Enfin, l'équipe de développement du core a recommandé via Twitter la troisième édition du livre "Learning JQuery".

Pour info, comme je l'ai suggéré, la JQcon et la JSconf, c'était ce weekend. J'espère pouvoir vous en parler rapidement. Vous pouvez déjà jeter un oeil aux photos de la JQcon. D'ailleurs, pour info, si les concernés se reconnaissent, un parapluie et un téléphone Motorola ont été oublié dans une des salles de conférence.

flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans jQuery, avec comme mot(s)-clef(s) , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.

8 réponses à Des nouvelles de jQuery, épisode 44

  1. Laurent dit :

    Bonjour Mathieu,
    merci pour tes post, tjrs très intéressants,
    avec la version 1.7, ont’ils améliorés le problème de width ou offsetwidth etc… quand l’élément est caché ?
    pour l’instant j’utilise une fonction maison qui prend l’élément qui l’affiche dans un autre en absolute hidden pour connaitre sa hauteur ou largeur. mais pas pratique car tous les styles doivent être dupliqué

    Laurent

    • Mathieu dit :

      Salut et merci ! Concernant width et offsetwidth, rien ne figure dans le changelog détaillé donc je dirais que non. A confirmer dans l’utilisation. Ceci dit, ça me rappelle un débat qui s’était tenu il y a quelques temps, je ne retrouve pas le lien, désolé. Grosso modo, des utilisateurs voulaient comme toi connaître la taille d’éléments du DOM caché. Je crois qu’il avait été décrété que si un élément est caché c’est qu’il « n’existe pas visuelle » et donc qu’il n’a pas de taille. Je simplifie un peu mais ce qui permet du coup de se dire que ça ne sera sûrement jamais changé.

      • Laurent dit :

        Merci Mathieu pour cette réponse. je vais donc me pencher dessus, et je pense que je vais faire une fonction qui remonte les parents de l’éléments jusqu’à trouver lequel et en display none, le mettre en block chercker le width et le remettre en none.
        je posterai ma fonction

        Cordialement,
        Laurent

        • Mathieu dit :

          C’est violent niveau performances ton idée. A mon avis tu ferais mieux de cadrer clairement et explicitement les éléments qui risquent de subir un hidden avec une classe. Par exemple en les préfixant « hidden-xxx ». Comme ça tu les sélectionnes directement. La recherche par styles va t’amener à des performances catastrophiques, plus que la recherche par classes, même si l’idéal reste par id qui a les meilleurs résultats. Pour une raison très simple qui est que celle-ci bénéficie de la fonction getElementByID native aux navigateurs, les autres sont du parcours de DOM…

  2. Salut Mathieu

    Concernant : « Reste à savoir si l’unification de bind() et live() ne va pas poser des soucis de performances. »

    Lors de l’introduction de la méthode delegate(), beaucoup plus performante, je me souviens qu’il a été écrit que la méthode live était en sursis.

    $(elems).on(events, selector, fn)
    $(document).on(events, selector, fn)

    Les deux méthodes on() sont identiques, avec la méthode delegate on pouvait également écrire :

    $(elems).delegate( selector, events, fn)
    $(document).delegate( selector, events, fn)

    Il n’y a pas d’unification. Je crois qu’il faut plutôt dire que la méthode live est obsolète depuis longtemps.

    • Mathieu dit :

      Salut Daniel !
      C’est vrai que vu sous cet angle… Merci de cette importante précision, ton point de vue est plus qu’intéressant. Et ma foi, pour des questions de performance, ce n’est peut-être pas un mal de rejeter live() « explicitement ».

  3. Syndrael dit :

    Ca me fait peur tous ces changements autour des gestionnaires d’événements.. Live et Delegate n’étaient pas si vieux que ça à mes yeux..
    A vouloir décréter trop d’éléments obsolètes ils risquent de perdre du monde qui ne s’est pas mis au courant des dernières avancées.. sans oublier JQueryUI..
    S.

    • Mathieu dit :

      Sincèrement ? De toute façon, les personnes qui ne mettent pas à jour leurs connaissances ne mettent pas à jour leur version. Bien évidemment, c’est une généralité que je fais là mais elle est volontaire car même si cela devait ne concerner que 90% des personnes ciblées, le reste à mon avis aura l’intelligence d’aller finalement se mettre à jour.

      Et pour le coup, à mon humble avis, l’obsolescence nouvelle de live() bien que cette fonction ne date que de la 1.4 (27 avril 2010) est plutôt un retour en arrière sur une décision qui s’est avérée ne pas être si bonne. L’outil en lui-même s’avère pratique, tellement pratique qu’il n’est plus usité uniquement pour ce pourquoi il a été pensé mais pour presque tout gérer. Introduisant au passage un grand nombre de mauvaises pratiques. Je comprends la décision, le débat derrière ça devenant : « faire simple mais en encourageant du coup de mauvaises habitudes, ou complexifier un peu mais en préservant le bons sens ?« .
      C’est l’essentiel des discussions qui se tiennent d’ailleurs dans la redéfinition d’APIs pour jQuery UI, même si la mentalité d’origine de jQuery était « faire plus en écrivant moins », ils ont aussi pris conscience de l’importance de leur produit dans l’apprentissage du JS pour beaucoup de développeurs. C’est un équilibre compliqué à atteindre, ici c’est live() qui en fait les frais.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Articles liés