jQuery, le bulletin hebdomadaire

Des nouvelles de jQuery, numéro 36

Flattr this!

Comme depuis quelques semaines, ça sent les vacances à plein nez et du coup ça bosse pas des masses en ce moment. Mais on a quand même de temps en temps des news intéressantes.

Tout d'abord une petite question de performances intéressante a été soulevé à propos de la sélection d'éléments de type hidden. L'idée étant de déterminer dans quels cas il vaut mieux utiliser ":hidden" plutôt que "input[type=hidden]". Je vous laisse découvrir les résultats ici et la conversation.

Côté jQuery UI, encore et toujours le DatePicker en vedette (sérieusement, personne ne se sert des autres modules ou quoi ?).Nous avons donc deux sujets. L'un parlant du support de l'année chinoise pour Taïwan, l'autre du calendrier perse et arabe.

J'ai vu passer un plugin intéressant d'accordéon vertical sur la FermeDuWeb. Le plugin s'appelle simplement : "Vertical Sliding Accordion". Vous pourrez trouver des démonstrations ici.

Côté jQuery Mobile, ils sont en pleine phase finale des tests de la beta 2. Du coup, si tout se passe comme prévu, elle devrait voir le jour dans la semaine. Peut être bien même aujourd'hui ! Surveillez donc bien le compte Twitter de l'équipe. Les tests sont désormais plus faciles grâces à un outil développé par Scott Jehl, du Filament Group, la boîte derrière l'essentiel de jQuery UI, qui a créé un outil appelé "Drive-In". En gros, lorsque vous testez une application sur un banc de plusieurs unités mobiles, l'outil permet de reproduire les actions sur une entité sur toutes les autres. Ce qui forcément accélère quelques peu les manipulations 😉

D'ailleurs l'équipe aurait besoin d'un coup de main pour appliquer les templates de documentation aux pages de documentation qui existent. Histoire d'avoir une doc d'API propre. Découvrez comment les aider ici.

D'ailleurs, un nouveau livre est disponible chez O'Reilly à propos de jQuery Mobile. "Jquery Mobile: Up and Running" est actuellement en pré-version et sera mis à jour à la sortie de la version 1. Je ne vous conseille donc pas de l'acheter pour le moment mais d'attendre la version mise à jour. Bien entendu je vous tiendrai au courant.

Toujours côté jQuery Mobile, l'équipe vous recommande de tester le plugin mobiscroll si vous êtes à la recherche d'un DateTimePicker efficace et compatible.

Enfin, Scott Jehl (toujours le même) organise un workshop pour "construire des applications avec jQuery Mobile", le 1 septembre à Brighton en Angleterre. Le tout dans le cadre de la conférence dConstruct 2011 qui aura lieu le lendemain au même endroit.

C'est tout pour aujourd'hui, à la semaine prochaine !

Note de fin d'article : Vous savez quoi ? J'ai sauté les numéros 33 et 34 sans m'en rendre compte. On mettra ça sur le compte de la fatigue hein.

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.
  • http://www.pure-tentation.fr/ Syndrael

    Concernant le DatePicker, c’est clair qu’il est utile même si j’avoue que des fois j’ai besoin de dériver certains événements.
    Par contre, un petit drop down menu..ça commence vraiment à manquer même si c’est sur la road map.
    S.

    • http://www.mathieurobin.com/ Mathieu

      Il serait intéressant d’avoir un jour des stats d’utilisation des widgets. Juste par curiosité.

      Le dropdown menu, comme tu le dis, est sur la road map. Espérons qu’il sera bientôt livré.

  • http://www.pure-tentation.fr/ Syndrael

    Sympa l’idée de benchmarker « input[type=hidden] » mais dans l’absolu est-ce vraiement utile ??
    1. on a rarement 300 hidden dans le formulaire
    2. on fait face à des navigateurs multiples et au final il est difficile de faire ressortir la solution ultime..
    S.

    • http://www.mathieurobin.com/ Mathieu

      J’ai essayé de vérifier ton argument 1 sur une bête page d’édition d’article de WordPress. Sélecteur : jQuery(‘:hidden’), résultat : 803.
      Donc oui et non. Sur des devs « classiques », effectivement peu de hidden. Mais dès que tu passes à une interface vraiment riche… on joue directement dans une autre catégorie. Je travaille sur un projet à titre personnel, je dois approcher les 200 hidden du fait d’être en total Ajax.
      D’où les sélecteurs jQuery qui essaient de rendre la compatibilité maximale. Cependant effectivement, celle-ci est relativement difficile à garantir.

      • http://www.pure-tentation.fr/ Syndrael

        Pour tes 200 hiddens, tu ne veux pas faire un seul hidden avec un beau tableau en JSON ?? A mon sens ce sera plus rapide..
        Finalement, tu n’as pas tort.. 800 hidden ou 800 éléments dans le DOM il y a peut etre une influence.. donc à voir..
        S.

        • http://www.mathieurobin.com/ Mathieu

          Ils ne sont pas forcément tous dans le même formulaire. Prenons un exemple parlant : un tableau éditable. Chaque ligne est un formulaire. Admettons que tu as un seul hidden par ligne, ce qui te fait, si tu as 20 enregistrements par vue dans ton tableau, 20 hidden déjà dans ta page. Plus les hidden probables qui te servent à gérer des filtres dans un formulaire de recherche lié au tableau, plus admettons je ne sais quel formulaire d’édition multiple positionné en display:none et affichable avec Javascript. Tout de suite t’en as beaucoup plus.
          Cependant, comme tu le disais dans ton premier commentaire, on a rarement 300 hidden dans un formulaire, ce qui devrait normalement d’abord permettre de filtrer sur un formulaire puis d’y chercher les hidden. Si c’est le cas, c’est que c’est très certainement mal conçu.

Articles liés