Yahoo! User Interface blog (YUIBlog)

Communiqué de YUI 3.4.0 Aperçu 3 est maintenant disponible sur CDN

L'équipe YUI vient de terminer le sprint finale de développement pour la libération 3.4.0. A ce moment nous considérons le code fonctionnellement complet. Nous prévoyons de passer notre prochain sprint se concentrant sur notre dernier tour de test et de créer plus d'exemples et de documentation. Nous avons affiché une FC (fonctionnelle complète) construire la CAN pour l'exploration et de la rétroaction. Vous pouvez accéder à cette libération à http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js .

Il ya quelques domaines particuliers de la bibliothèque où nous serions ravis d'avoir rétroaction de la communauté:

• Loader a eu une mise à jour importante pour les 3.4.0. Si vous faites spécifications de charge manuelle via use("*") ou utiliser des configurations sous-module, nous serions très reconnaissants que vous essayez votre code avec le nouveau chargeur pour être sûr que nous sommes bien traiter tous les cas d'utilisation. Pour plus d'informations sur les changements Loader dans le présent communiqué, consultez le blog décrivant les changements Loader 3.4.0 .
• Calendrier et le Groupe sont entièrement fonctionnel et prêt pour une utilisation développeur.
• Graphisme:. Il ya eu un changement API rares qui affectent tout code expérimentale écrite sur l'API graphiques distribués dans le communiqué de PR2 getShape() a été renommé addShape() . Il ya également eu plusieurs remplacements d'attributs.
• Transition: les transitions natives sont désormais pris en charge dans Firefox.
• WidgetButtons a été libéré comme une extension Widget nouvelles qui vous permet de placer css-style des boutons dans l'en-tête et pied de page de n'importe quel widget qui implémente le support des modules standard.
• Widget plugins-modalité et Widget-AutoHide ont été converties à des extensions.
• Widget: Ajout du support pour détruire (vrai) qui va enlever et détruire tous les nœuds enfants (et pas seulement le BoundingBox et ContentBox) contenues dans boundingBox du widget. destroy () maintiendra son comportement actuel en raison de l'potentiellement élevé d'exécution coût de la destruction de tous les nœuds enfant. Si vous détruisez Widgets dans votre application ou êtes un développeur widget personnalisé, votre aide pour tester ce changement serait appréciée.
• ScrollView supporte maintenant pagination verticale, inclut un plugin ScrollView-liste pour ajouter classnames CSS à des éléments de liste immédiate, ainsi que plusieurs corrections de bugs et le refactoring
• App-cadre: Nous voulons exprimer mes sincères remerciements à tous les développeurs de la communauté qui ont pris le temps de tester le nouvel App-cadre. Nous avons reçu d'excellents commentaires après la publication PR2. S'il vous plaît continuer à explorer ces composants et nous envoyer vos observations et suggestions.

Vous pouvez obtenir des renseignements supplémentaires sur le contenu de ce communiqué en passant en revue l' histoire de cumul et la liste complète des billets adressée au PR3 . S'il vous plaît le fichier des demandes d'amélioration, bugs et des régressions dans la base de données sur les billets YUILibrary.com .

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

YUI: Open Heures jeu. Juillet 28th

Y.Calendar vient à 3.4.0

Calendrier est un de nos widgets plus populaires dans les YUI deux familles, et c'est fait ses débuts sur la YUI 3 architecture en 3.4.0. Allen Rabinovich est le propriétaire des composants et l'auteur et sera sur la réintroduction de nous appeler à ce vieux favori, montrant quelques nouvelles approches aux problèmes rencontrés par 2.x Calendrier. Je suis particulièrement enthousiasmé par le soutien à l'internationalisation, mais les règles de rendu nouvelles sont également assez fascinant.

Viens, et apporter votre dattier, l'événement de calendrier, l'import-de-iCal et-faire-crêpes aux questions et demandes de fonctionnalités avec vous comme nous étoffer le présent et l'avenir Y.Calendar . (Non, il ne sera pas à l'importation iCal, mais si quelqu'un veut créer un module de galerie d'apprivoiser cette bête, il est sûr d'être un billet YUIConf-il pour vous;))

Nous sommes de retour à notre heure habituelle de cette semaine, nous allons donc vous voyez dans Connect à 10h PST.

Temps & Détails

Nous allons être en ligne 10 heures-11 heures HAP jeudi. Les détails de connexion sont les mêmes que d'habitude.

1. Composez 1-888-371-8922 pour (Skype fonctionne très bien pour les participants hors États-Unis *)
2. Entrez le code 47188953 # participant
3. Joignez-vous à la session de partage d'écran (ce qui vous invite à installer le plugin Adobe Connect si c'est votre première fois à l'utiliser)

Remarque: Parce que c'est une conférence en ligne ouverte, nous demandons que les appelants mute leurs lignes à moins qu'ils ne participent à une discussion active.

* - Si Skype n'est pas une option, écrivez-moi ou attraper moi (ls_n) dans le canal # yui IRC sur Freenode pour un numéro local.

Enregistrement

Merci à tous pour appeler en! L' enregistrement en ligne de la session est maintenant disponible.

La haute qualité, l'iPhone / iPad compatibles, l'enregistrement téléchargeable ici .

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

YUI: Open Heures jeu. Juillet 21st

Une mise à jour DataTable et une galerie vitrine

3.4.0 Le cycle de libération est venue à sa fin et seront emballés avec toutes sortes de fonctionnalités, mais parles ouvertement, DataTable a pas eu beaucoup de développement que l'accent comme il aurait dû. Il ya eu quelques corrections de bugs, cependant, et une bonne dose de planification des changements qui sont ciblés dans 3.5.0, et un excellent début de participation de la communauté à son développement.

Nous savons que DataTable est un widget très important pour beaucoup de clients, alors nous comprenons le coût de retarder le développement ciblée. Cette Heures d'ouverture sera une mise à jour sur ce travail se fait pour les 3.4.0, ce qui est prévu pour le 3.5.0, et une introduction à l'excellent travail qui est commencé à surgir dans la Galerie d'ajouter des fonctionnalités et de corriger les bugs pour le DataTable (et sa famille de soutenir les classes).

Nous allons être en ligne d'une heure plus tôt cette semaine pour le bénéfice de Eamon Brosnan (alias, mosen de # yui), qui a fourni un certain nombre de correctifs Galerie nous allons nous pencher plus. Sinon, nous aurons d'autres habitants # yui et contributeurs Galerie montrant leurs marchandises. Si vous avez une solution DataTable ou travaux en cours que vous aimeriez partager, s'il vous plaît laissez-moi savoir si je peux bloquer le calendrier de tout combiner (ls_n dans # yui ou Twitter ).

Temps & Détails

Nous allons être en ligne 9 heures-10 heures HAP jeudi. Les détails de connexion sont les mêmes que d'habitude.

1. Composez 1-888-371-8922 pour (Skype fonctionne très bien pour les participants hors États-Unis *)
2. Entrez le code 47188953 # participant
3. Joignez-vous à la session de partage d'écran (ce qui vous invite à installer le plugin Adobe Connect si c'est votre première fois à l'utiliser)

Remarque: Parce que c'est une conférence en ligne ouverte, nous demandons que les appelants mute leurs lignes à moins qu'ils ne participent à une discussion active.

* - Si Skype n'est pas une option, écrivez-moi ou attraper moi (ls_n) dans le canal # yui IRC sur Freenode pour un numéro local.

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

Next-Gen YSlow alimenté par YUI

A il ya quelques semaines, Yahoo a annoncé YSlow pour Mobile au Velocity 2011 , portant la puissance d'analyse de performance YSlow pour le monde mobile.

YSlow pour mobile fonctionne comme un bookmarklet , ce qui permet de fonctionner sur d'autres navigateurs que Firefox (comme un add-on) ou de chrome (comme une extension) .

L'architecture a été partiellement redessinée YSlow pour travailler multi-plateforme et YUI a été le facteur essentiel de faire des sandboxing, cross-browser abstraction et simples d'accès YQL possible.

Sandboxing

Afin d'être incorporé dans une page, sans interférer avec l'analyse de performance et sans déconner avec la page elle-même, YSlow est un bookmarklet qui injecte JavaScript et CSS dans n'importe quelle page en mobilisant la puissance de YUI sandboxing:

URL Bookmarklet:

 javascript: (function (y, p, o) {
     p = y.body.appendChild (y.createElement ('iframe'));
     p.id = 'YSlow-bookmarklet »;
     "display: none '= p.style.cssText;
     o = p.contentWindow.document;
     o.open (). write ('
         <head>
         Onload du corps <= "
             YUI_config = {
                 gagner: window.parent,
                 doc: window.parent.document
             };
             var d = document;
             d.getElementsByTagName (\ '\ tête') [0]
                 . AppendChild (
                     d.createElement (\ 'script \')
                 ). Src = \ 'http://d.yimg.com/jc/yslow-bookmarklet.js \' "
         >
     ');
     o.close ()
 } (Document))

Le code ci-dessus:

• crée un vide iframe;
• elle ajoute à l'organisme de la page;
• * cache les iframe;
• obtient son gestionnaire de fenêtre;
• écrit dans son contenu le corps de l'iframe;
• ce corps est vide, mais a un onload événement
• l' onload événement définit comment injecter YSlow JS:
  • ensembles YUI_config , donc win et doc pointe vers la page en cours d'analyse window et de document , respectivement
  • injecte dynamiquement URL YSlow en créant un script l'élément dans la iframe head

* L'iframe est affiché par le temps tous les actifs de présentation YSlow sont chargés

Cela placera un iframe dans la page en cours d'analyse. Cette iframe agira comme un environnement isolé et YSlow va résider en son sein. Depuis l'iframe est créé dynamiquement sans le src attribut, il aura accès à son parent (la page en cours d'analyse) car il n'ya pas de même origine politique de la violation qui s'y passe.

Le YUI_config objet est utile, car elle établit win et de doc pour le parent de l'iframe (la page en cours d'analyse), donc toute nouvelle instance YUI sera lié au document parent par défaut, le câblage tout appel à Y.all et Y.one travers Y.config.win ou Y.config.doc de la YUI use de rappel.

Présentation YSlow est géré par l'iframe window et de document référence, permettant le script YSlow principale de rendre le balisage ainsi que chercher le CSS externes dans ce iframe sans entrer en conflit avec des styles de la page parent. YSlow scans de la page parent afin d'obtenir tous les éléments (images, scripts, liens, images d'arrière-plan, flash, etc) requises pour l'analyse des performances ultérieures. Ceci est fait en accédant Y.config.win et Y.config.doc , car ils renvoient à la page parent.

Cross-browser abstraction

Être un bookmarklet, YSlow pour Mobile est censé fonctionner sur n'importe quel navigateur *. YUI résumés cross-browser questions en normalisant les différences navigateur, résultant en un endroit propre, facile à lire et à base de code maintenable.

YSlow n'a pas été entièrement portée sur YUI 3 - seule la couche contrôleur (à partir du composant Application à venir) pour le moment - mais encore, toutes les manipulations du DOM et de la gestion des événements sont effectuées par le node et le event des modules. Dans les versions futures, nous prévoyons au port fonctionnalités YSlow plus à YUI 3.

* Tous les navigateurs sont actuellement pris en charge

YQL

YSlow analyse les pages en vérifiant les en-têtes HTTP pour les composants trouvés sur la page. Têtes de réponse HTTP ne sont pas disponibles dans la page, d'où ces composants doivent être demandés à nouveau afin d'obtenir l'information YSlow tête de réponse. Ceci pourrait être réalisé en demandant la liste des URL composant via XMLHttpRequest (AJAX), mais malheureusement à cause de la restriction d'origine même politique , ce n'est pas possible à moins que tous les composants sont dans le même domaine que la page qui est très peu probable.

Une solution de contournement pour la restriction commune d'origine même politique est d'utiliser JSONP, où un serveur externe fonctionne comme un proxy demandant la liste des URL des composants et la récupération de leurs têtes de réponse HTTP pour le compte de YSlow. En raison de la popularité YSlow et mobiles récents efforts d'analyse de performance, nous nous attendons à la circulation assez lourd pour le YSlow pour bookmarklet Mobile. Afin de soutenir un tel trafic, YQL était la solution évolutive adoptée par YSlow travers une ouverture tableau de données nommée data.headers , qui récupère les en-têtes de réponse et le contenu pour une liste donnée d'URL tout en imitant le user-agent pour assurer le contenu attendu est récupérées.

La requête YQL composante fait tout le travail de gestion des requêtes, tout en gérant les demandes YQL JSONP sous le capot, rendant le code du contrôleur YSlow beaucoup plus simple et facile à entretenir.

Les futures améliorations: YSlow Nouvelle interface conviviale mobile

Actuellement, le YSlow pour l'expérience utilisateur mobile est le même que l'expérience du bureau. Faire face à une longue liste de données d'analyse des performances n'est pas la meilleure expérience sur les petits écrans de téléphone intelligent. Depuis YUI résumés également cross-device gestes , YSlow pour Mobile obtiendront une nouvelle marque mobiles interface conviviale dans les versions futures.

Performance de l'outil de la performance

YSlow pour le déploiement de Mobile a été faite avec soin compte tenu de son impact sur les performances sur le temps de chargement de la page en cours d'analyse. Les 3 modules YUI utilisé sur YSlow ont été examinés afin d'inclure uniquement les modules nécessaires pour charger YSlow aussi vite que possible. Le fichier de graines et de YUI Loader n'ont pas été inclus , depuis tous les modules nécessaires et sous-modules suivants ont été combinés performance zen Ryan Grove conseils, ce qui rendait possible de charger tout ensemble en une seule requête seule petite: YSlow-bookmarklet.js: 204KB, 66KB ( gzip) où:

• YUI: 75KB, 27KB (gzip)
• YSlow: 129KB, 39KB (gzip)

En savoir plus sur YSlow

Tenez-vous au courant des dernières annonces YSlow par:

• Visiter la page de YSlow redessiné au getyslow.com
• Liking YSlow sur Facebook: facebook.com / getyslow
• Après YSlow sur Twitter: twitter.com / getyslow

A propos de l'auteur: Marcel Duran est le principal Front End pour l'équipe de Yahoo! Performance exceptionnelle. Il a été dans l'optimisation des performances Web sur des sites à fort trafic dans Front Page Yahoo! et les équipes de recherche où il a demandé et étudié les pratiques les meilleures performances web création de pages encore plus vite. Il est désormais dédié à la performance YSlow et d'autres outils de développement, les recherches et l'évangélisation. Son objectif est de rendre le web plus vite que cela peut être et croit qu'il n'ya pas une telle chose comme «juste quelques millisecondes ne fera pas mal».

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

Graded Update Support du navigateur

Modifications GBS

Les changements spécifiques à cette mise à jour comprennent:

• Pas plus attribuer des notes d'expérience
• Abandonnées prescrivant les systèmes d'exploitation spécifiques (sauf pour les mobiles)
• Ajouté une couverture pour Internet Explorer 9
• Ajouté couverture pour Firefox 4 †.
• Ajouté couverture pour Firefox 5. †

Notes:

• Le symbole poignard (comme dans "Firefox 4. †») indique que la plus actuelle de non-version bêta à ce niveau de la branche reçoit un soutien.
• Aucune orientation n'est donnée sur iOS ou d'utilisation appareil Android OS. La recommandation est que vous choisissez les périphériques qui sont les plus représentatifs de votre base d'utilisateurs pour chaque OS.

Suppression de la ligne de base Grades Browser Test

Cette édition de la mise à jour GBS représente un départ de nos mises à jour précédentes en ce que nous nous éloignons des navigateurs cartographie directement aux grades d'expérience (par exemple "A-grade" et "C-grade»). Plutôt que de prescrire ce l'expérience utilisateur est approprié pour les navigateurs, nous allons nous concentrer sur la définition d'une stratégie efficace de test de base qui maximise la couverture de test et minimise la surface d'essai. Par exemple, IE6 est encore significatif de parts de marché mondiales justifie la poursuite des essais; GBS Mais aujourd'hui permet de l'expérience utilisateur IE6 d'être différent de l'expérience IE9.

Suppression des systèmes d'exploitation de la base de test du navigateur

Afin de rationaliser le test et de minimiser les besoins en ressources, nous n'avons plus spécifier quel système d'exploitation devrait être testé sur. La seule exception est lorsque le navigateur est étroitement couplé avec la version OS, auquel cas nous nous référons à la version OS plutôt que la version du navigateur (par exemple "iOS Safari 4"). Cela nous permet de concentrer la couverture des tests sur des versions de navigateur, et de minimiser les tests redudant toutes les plateformes. Problèmes avec le même navigateur à travers les versions sont négligeables, et généralement liées à des différences de niveau supérieur OS, tels que la gestion des clés et des polices disponibles. Le code qui est connu pour aborder les problèmes multi-plateforme devrait être testé sur plus de plateformes que possible, mais ce test ne peut généralement être isolées aux problèmes spécifiques plutôt que de courir un test de régression complète de toutes les fonctionnalités. Nous recommandons alignement des priorités des tests du système d'exploitation avec votre base d'utilisateurs.

Pourquoi est-IE6 encore sur la liste?

IE6 a encore une importante part du marché mondial suffisamment pour justifier d'une expérience utilisateur vérifié acceptable. Une idée fausse commune avec la stratégie d'amélioration progressive a été qu'une fois qu'un navigateur passe "C-grade" qui devient "non supporté", alors qu'en fait, que signifie vraiment qu'il devrait être livré l'expérience HTML seulement. Maintenant que nous n'avons plus prescrire les navigateurs qui reçoivent ce que l'expérience, cela est laissé pour des projets de décider en fonction de leurs utilisateurs et de ressources. Le SGB est axé sur la spécification dont les navigateurs ont besoin d'une expérience vérifiée utilisable en fonction de facteurs tels que la part de marché et d'influence. Définir ce qui est «utilisable» et spécifiant des niveaux acceptables de dégradation sont laissés aux équipes de décider. Nous avons encore la promotion d'une simple amélioration progressive du modèle, et de décourager les projets de la création de nouveaux niveaux sans tenir compte des coûts supplémentaires en matière de développement, les tests et les ressources de maintenance.

Prévisions GBS

Nous nous attendons à effectuer les modifications suivantes dans la prochaine mise à jour:

• Cesser de couverture pour Safari sur iOS 3.
• Ajouter une couverture pour Webkit sur Android 3.
• Ajouter une couverture pour Firefox 6.
• Ajouter une couverture pour Safari iOS 5.

Les archives du GBS

• GBS Update, 03/11/2010
• GBS Update, 16/02/2010
• GBS Update, 16/10/2009
• GBS Update, 02/07/2009
• GBS Update, 2009-01-28
• GBS Update, 03/07/2008
• GBS Update, 2008-02-19

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

L'extension "MakeNode" Widget

Dans mon précédent article, une recette pour un YUI 3 Application , j'ai montré une façon d'utiliser Y.substitute comme un processeur de modèles très simples. L'idée a pris la vie à partir de là, avec les suggestions des gens dans le canal # yui IRC, et je me suis fait une extension de widget qui est disponible sur mon site, appelé MakeNode . MakeNode n'est pas un processeur de modèles génériques et il n'est pas conçu comme un. D'autre part, il est étroitement intégré à la YUI Widget classe de fondation, y compris les aides className et d'événements et d'internationalisation. Dans cet article, je vais prendre le Spinner exemple et le modifier à suivre les directives de mon article précédent et à utiliser MakeNode. La composante Spinner modifiés ( JS , CSS , sprites ) ainsi que d'un exemple sont disponibles sur mon site. Liens vers d'autres ressources peuvent être trouvés à la fin de cet article.

Étendre votre composant

Une fois MakeNode est chargé, vous devez inclure le module dans votre YUI().use() énoncé en utilisant le nom 'makenode' . Puis, pour prolonger votre widget, vous la liste dans le troisième argument à Y.Base.create() , comme ceci:

  Y. Spinner = Y.Base.create (
      «Spinner»,
      Y. Widget,
      [Y. MakeNode],
      {
         / Membres d'instance / ...
      },
      {
          / / Membres statiques
      }
 ); 

Vous pouvez ajouter MakeNode tout au long certain nombre d'extensions appropriées pour Widget, telles que WidgetParent, WidgetChild, WidgetStdMode, etc MakeNode ajoute deux méthodes protégées, _makeNode et _locateNodes, et il sera lu à partir de plusieurs propriétés statiques, s'il est trouvé.

Tous les membres de cette extension sont soit protégés ou privés, car ils sont destinés à être utilisés par le développeur du composant et non par l'opérateur en utilisant ces composants, qui ne devraient pas être dérangé par eux.

Définition du modèle

La première chose que vous aurez normalement faire est de définir le modèle de votre composant. Pour le Spinner, notre modèle sera:

  _TEMPLATE: [
     "<input Type="text" title="{s input}" class="{c input}">»,
     «<button Type="button" title="{s up}" class="{c up}"> </ bouton> ',
     «<button Type="button" title="{s down}" class="{c down}"> </ bouton> '
 ]. Join ("\ n"), 

Le modèle par défaut sera généralement appelé _TEMPLATE et déclarée le long des autres propriétés statiques de la classe, comme ATTRS . MakeNode va utiliser ce modèle, si aucun autre n'est explicitement prévu. Le modèle est composé de HTML brut, plus une série de marqueurs entre accolades, chaque fait d'un seul caractère (le code de traitement) et suivi par un ou plusieurs arguments. Les espaces réservés et ce qu'ils produisent sont:

• {@ attributeName} valeur de l'attribut de configuration

• {p propertyName} valeur de la propriété par exemple

• {m methodName arg1 arg2 ….} valeur de retour de la méthode donnée. Le code de traitement est suivi par le nom de méthode et un nombre quelconque d'arguments séparés par des espaces. Les chaînes doivent être placées entre guillemets doubles. Nombres, booléens et null sera converti de cordes à leur bonne types de données

• {c classNameKey} className CSS générés par la _CLASS_NAMES propriété statique

• {s key} de la chaîne de strings d'attributs, en utilisant key comme l'attribut sous-traitant.

• {? other placeholder } Produit de la chaîne checked lorsque le résultat du traitement du reste de l'espace réservé est vrai.

• {} toute autre valeur sera traitée comme Y.substitute fait.

Par exemple, {@ value} se traduira this.get('value') alors {p value} se traduit par this['value'] .

Le {m} espace réservé est un peu plus complexe. Le premier argument après le m code de traitement est le nom de la méthode et le reste des arguments, tous séparés par des espaces, qui sera transmis à la méthode donnée. Ces arguments peuvent être des nombres, null , true , false ou chaînes entre guillemets. MakeNode va les analyser et les convertir à leurs types correcte, donc {m myMethod 123.45 true “this is a string”} donnera lieu à appeler this.myMethod(123.45, true, “this is a string”) afin que les deux premiers arguments sont convertis à leur correcte des types de données et la chaîne peut contenir des espaces. Pour inclure un guillemet double, utilisez \\" , la double barre oblique inverse soit nécessaire car les scripts JavaScript va interpréter une seule et il se défait avant qu'il arrive à MakeNode. Seuls les guillemets sont autorisés, MakeNode ne pas utiliser eval() de sorte que l'analyseur est limitée mais sûre. Tout sauf numéros, null , booléens et de chaînes entre guillemets seront ignorés.

Le {?} espace réservé est très pratique à utiliser avec des cases à cocher et des boutons radio. Elle produira de la chaîne “checked” selon la valeur de vérité de l'instruction de traitement de code qui suit. Ainsi, <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> va produire une case marquée si l' getLength méthode renvoie tout sauf zéro. {?} sera accepté aucun des autres espaces réservés, même si elle n'a de sens avec les trois premiers.

Pour le {c} espace réservé, nous avons besoin d'avoir un _CLASS_NAMES biens définis.

Espaces réservés supplémentaires peuvent être ajoutés à MakeNode en les ajoutant dans le _templateHandlers hachage.

La propriété _CLASS_NAMES

Avec le ATTRS et _TEMPLATE attributs statiques, on peut définir un _CLASS_NAMES propriété qui pointe vers un tableau de chaînes. Chacune de ces chaînes sera utilisé pour générer un className. Ainsi _CLASS_NAMES: ['input'] produira le className “yui3-spinner-input” . Ceux classnames sont stockés dans une propriété d'instance this._classNames . L' {c input} l'espace réservé dans le modèle ci-dessus sera remplacé par “yui3-spinner-input” .

Vous pouvez utiliser le _CLASS_NAMES la propriété de générer un nombre illimité de noms de classes, si vous les utiliser dans le modèle ou pas. Vous pouvez encore rejoindre ces noms de classe supplémentaire à partir de l'intérieur this._classNames . Le className est généré en utilisant l' yui3 préfixe suivi par la valeur de l' NAME propriété statique transformé en minuscule, puis la chaîne donnée dans _CLASS_NAMES (cette dernière ne sera pas mis en minuscules), tous séparés par des tirets. Le _classNames hachage contiendra également les noms de classes pour la boundingBox et le contentBox , la première sous le "." clef et le second sous le “content” clés. Widget assigne à l' boundingBox l'classnames dérivés des valeurs de l' NAME propriété de chacune des classes dans la chaîne d'héritage, à commencer par yui3-widget . Magasins MakeNode en this._classNames seulement le className haut pour la plupart des boundingBox .

Si un composant est à plusieurs niveaux loin de Widget, comme SuperSpecialSpinner héritant de SuperSpinner qui hérite de Spinner qui hérite de Widget, et si tout ou partie d'entre eux ont _CLASS_NAMES propriétés définies, MakeNode va produire classnames pour chacun d'eux et de les stocker dans this._classNames . Vous n'avez pas besoin d'inclure, à chaque niveau les noms déjà déclaré dans les niveaux précédents. En fait, il vaut mieux que vous n'avez pas produit depuis les noms de classe à chaque niveau va utiliser la valeur de l' NAME propriété de ce niveau. Ainsi, dans SuperSpecialSpinner , {c input} sera encore aboutir à “yui3-spinner-input” et non “yui3-superspecialspinner-input” et si elle permet de conserver votre fichier CSS reste valable.

L'espace réservé {s}

Widget a strings attribut de configuration définies, même si elle n'est pas initialisée avec une valeur quelconque. Cet attribut est destiné à tenir les chaînes qui sont visibles à (ou via les lecteurs d'écran, la lecture à) l'utilisateur. Il est important que vous n'avez jamais inclure des chaînes visibles directement dans le modèle. Ce n'est pas une exigence de MakeNode - il n'a jamais été une bonne idée du tout. Toutes les chaînes qui doivent être considérées par ou lu à l'utilisateur doit toujours être placé dans la strings d'attributs. Les strings attribut contient un hash, où chaque texte se situe par sa clé. La composante Spinner a les chaînes suivantes, dont vous pouvez voir utilisés dans le modèle ci-dessus.

  chaînes: {
     valeur: {
         entrée: ". Appuyez sur la flèche haut / bas pour des incréments de mineurs, page haut / bas pour des incréments majeur»,
         jusqu'à: «Increment»,
         bas: «décrément»
     }
 }, 

La meilleure partie de ce faire est que votre composant peuvent être localisés dans d'autres langues très facilement par les développeurs utilisant votre composant. Lors de la création d'une instance de Spinner, vous pourriez faire:

  var = new mySpinner Spinner ({cordes: Y.Intl.get («spinner')}); 

Réglage de l'attribut de configuration strings de cette manière remplace la valeur par défaut strings valeurs avec celles du fichier de ressources linguistiques en utilisant le langage défini précédemment. Le {s} accède à l'espace réservé chaînes stockées dans les strings d'attributs, soit ceux par défaut ou celles traduites, si elle est définie. Le {s xxxx} espace réservé est, en fait, rien de plus qu'un raccourci vers le {@ strings.xxxx} espace réservé. Cependant, la première ne peut accéder aux chaînes au niveau supérieur alors que, par exemple, {@ strings.xxxx.yyyy.zzzz} vous permettra d'accéder à une chaîne plus bas.

L'utilisation de _makeNode renderUI

Nous utilisons le modèle pour créer le balisage pour notre composant. Pour ce faire, nous pouvons appeler MakeNode de _makeNode méthode, comme ceci:

  renderUI: function () {
     . this.get ('ContentBox') append (this._makeNode ());
 }, 

Ce sera de remplir le contentBox de notre widget avec le balisage du traitement du modèle. Le _makeNode méthode retourne une instance de Y.Node , qui peut être ajouté ou inséré n'importe où ou vient de se tenir pour une utilisation ultérieure. Il ne retourne pas une chaîne, elle produit un Node par exemple.

Le _makeNode méthode prend deux arguments optionnels: une référence à un modèle et un objet à remplir dans des espaces réservés, comme Y.substitute fait. Dans notre exemple, Spinner simples il ya un modèle unique pour le widget entier, mais d'autres widgets pourraient exiger des morceaux faits de plusieurs modèles. Dans ce cas, vous appelons habituellement _makeNode sans arguments, pour la partie principale, et l'appeler une fois de plus avec des modèles différents de remplir les pièces supplémentaires. L' exemple contient cette renderUI méthode:

  renderUI: function () {
     var = fieldset this._makeNode ();
     this.each (function (item) {
         fieldset.appendChild (this._makeNode (MultipleTemplates.RADIO_TEMPLATE, point));
     }, This);
     . this.get ('ContentBox') append (fieldset);
 } 

Le premier appel à _makeNode retourne un Node par exemple stocké dans la variable fieldset . La composante de l'échantillon est également étendu avec Y.ArrayList donc le RADIO_TEMPLATE sera rempli avec les valeurs prises à partir des éléments stockés dans la liste de tableau et les noeuds résultants annexé au fieldset avant qu'il ne soit finalement annexé au contentBox . Les espaces réservés spéciaux tels que {@} ou {p} sera toujours se référer à des attributs ou des propriétés de l'objet principal. Les éléments imbriqués seront traitées comme Y.substitute serait.

La méthode _locateNodes

MakeNode prévoit en outre une _locateNodes méthode qui va essayer de localiser tous les éléments avec les noms de classe déclarée dans _CLASS_NAMES . Pour localiser les éléments spécifiques que vous pouvez passer n'importe quel nombre de clés className, autrement, _locateNodes essaie tous. Pour chaque élément trouvé de chaque className, _locateNodes va produire une propriété privée par exemple en utilisant le préfixe de soulignement suivi par le nom de la clé et le “Node” suffixe. Ainsi, dans notre exemple Spinner, _locateNodes va générer les propriétés _inputNode , _upNode et _downNode . Si plusieurs éléments ont les mêmes className, _locateNodes retournera une référence à la première d'entre elles. Si un élément n'est pas trouvé, aucune variable sera créé.

Dans la composante Spinner nous utilisons _locateNodes après la création du balisage:

  renderUI: function () {
     . this.get (CBX) append (this._makeNode ());
     this._locateNodes ();
 }, 

Le _EVENTS propriété statique

Une autre propriété peut être définie à l'instar de _TEMPLATE et _CLASS_NAMES et c'est _EVENTS . _EVENTS contient un hash composé de touches de nom de classe, chacune contenant un hash de types d'événements et de méthodes pour les gérer. Il est mieux expliqué par un exemple:

  _EVENTS: {
     '.': {
         clé: {
             FN: «_onDirectionKey»,
             args: ((Y.UA.opera) "en bas:":!? "presse:") + "38, 40, 33, 34"
         },
         mousedown: «_onMouseDown '
     },
     '..': {
         mouseup: «_onDocMouseUp '
     },
     entrée: {
         changement: «_onInputChange '
     }
 }, 

_EVENTS est un objet (une table de hachage) avec n'importe quel nombre de propriétés. Les noms des propriétés, qui est, les touches du hachage, identifier les éléments dont les événements nous allons écouter. Ils sont les mêmes identifiants utilisés dans _CLASS_NAMES . Il ya deux touches spéciales supplémentaires "." et ".." . Alors que les clés className référence à des éléments imbriqués dans le contentBox , le "." clés se réfère à la boundingBox lui-même tout ".." se réfère au document contenant ce widget. Considérez-les comme faire un chdir commande lorsqu'il se trouve à la boundingBox niveau. Le _EVENTS propriété est traitée après la renderUI , bindUI et syncUI méthodes ont été appelés afin que le widget est prévu pour être déjà insérée dans le corps du document, sinon le ".." va échouer.

Chacune des entrées dans _EVENTS est un autre objet qui utilise le type d'événement comme clé et le nom d'une méthode d'instance de le gérer. _EVENTS , étant une variable statique, n'a pas accès à this sorte qu'il ne peut pas prendre les références de fonctions réelles, seul le nom de la méthode d'écouteur d'événement. Certains types d'événements ont besoin d'arguments supplémentaires, telles que la key l'événement. Dans ce cas, au lieu de fournir le nom du gestionnaire d'événements que vous pouvez fournir un objet avec des propriétés fn et args pour contenir le nom de fonction et les arguments supplémentaires, si nécessaire.

MakeNode va utiliser Node.delegate d'écouter les événements des éléments imbriqués, alors qu'il va utiliser Y.on d'écouter les événements de la boundingBox et le corps du document. (Remarque: l'écoute de la key l'événement sur ​​tout élément imbriqué ne fonctionne qu'avec la version 3.4.0pr1 et au-dessus, puisque la délégation de l' key .. événement n'a pas été disponible avant toutes les caractéristiques d'autres travaux avec les versions précédentes)

Le _EVENTS déclarations sont cumulatifs lorsque les composants héritent les uns des autres. Chaque classe dans la chaîne d'héritage aura son propre _EVENTS déclaration traitées séparément.

Le _ATTRS_2_UI propriété statique

Evénements dans les deux sens, à partir de l'interface utilisateur pour le composant et de la composante de l'interface utilisateur. Les premiers sont gérés par le _EVENTS propriété. Puis il ya les événements déclenchés par des changements de valeur d'attribut qui doivent se refléter dans l'interface utilisateur. Comme je l'ai mentionné dans l'article précédent, quand il ya des éventuels effets secondaires de modifier un attribut de configuration, ils doivent être manipulés par les auditeurs événement de changement, et non par le Protocole facultatif setter méthode de l'attribut, ce qui ne devrait traiter que la normalisation de la valeur définie. L'interface utilisateur devrait refléter l'état des attributs de configuration, d'abord dans syncUI , lorsqu'il est initialisé, puis sur chaque événement de changement d'attribut. Pour ces derniers, nous avons besoin d'attacher un écouteur d'événements, qui nous faisons dans bindUI . Widget fournit déjà un mécanisme pour rendre aussi simple que cela, que j'ai décrit dans les commentaires de l'article précédent.

Widget utilise la propriété d'instance _UI_ATTRS qui contient un objet avec deux autres propriétés, SYNC et BIND . Chacun d'eux est un tableau énumérant les noms des attributs de configuration initialement être synchronisé puis écouté afin de garder l'interface utilisateur qui reflète les valeurs actuelles. Widget attend de chacun de ces entrées d'avoir une méthode qui lui est associé, nommé d'après le nom d'attribut préfixé par _uiSet avec le premier caractère de l'attribut name convertis en majuscules d'avoir le nom de méthode dans le cas de chameau bon. Ainsi, si "value" a été inscrite dans l'un des _UI_ATTRS tableaux (dans les deux SYNC ou BIND ), Widget s'attendrait à trouver une _uiSetValue méthode. Cette méthode reçoit deux arguments, la value définie et src du changement. Ceci est le code de notre Spinner _uiSetValue méthode:

  _uiSetValue: function (valeur, src) {
     if (src === IU) {
         retour;
     }
     this._inputNode.set (VALEUR, this.get (formateur) (valeur));
 }, 

Tous les identifiants en majuscules que vous voyez dans ce morceau de code correspondent aux constantes de chaîne déclaré ailleurs, pour permettre le compresseur YUI à mieux faire son travail. La méthode, essentiellement, définit les value d'attributs HTML dans le <input> case pour la série nouvelle valeur, après avoir été formaté. La référence à la zone de texte a été fourni par _locateNodes . Le src argument est d'abord vérifié pour voir s'il est réglé sur la valeur de chaîne 'ui' . Si tel est le cas, aucune action ne sera prise. Ceci est pour éviter les boucles infinies. Si l'utilisateur saisit quelque chose dans la zone de saisie, sa valeur serait aller dans la value l'attribut de configuration qui serait alors le feu une valueChange événement, qui se _uiSetValue appelé qui, si rien n'est fait, alors aller changer la valeur de la zone de saisie, ce qui déclencherait le processus entier de nouveau. Ainsi, dans _uiSetValue , si nous savons que le changement vient de l'interface utilisateur, nous ne faisons rien et si briser la boucle. Cependant, cela nécessite un autre morceau de code ailleurs. Dans l'écouteur pour l'événement DOM, lorsque nous avons créé l'attribut de configuration, nous utilisons le troisième argument optionnel à définir, comme ceci:

  _afterValueChange: function (ev) {
     this.set (VALEUR, ev.newVal, {src: UI});
 } 

C'est à nous de s'assurer que les modifications provenant de l'interface utilisateur sont marquées ainsi et puis vérifiez que même drapeau pour éviter les boucles.

Avec tout cela dit, je n'ai pas encore mentionné la propriété statique _ATTRS_2_UI mentionné dans le titre de cette section. Comme les commentaires dans mon article précédent montre (à travers les maladresses que j'ai fait en eux), en s'assurant que tous les attributs qui affectent l'interface utilisateur sont correctement répertoriés est quelque peu désordonné. Vous ne devriez jamais initialiser _UI_ATTRS à partir de zéro depuis Widget listes déjà tout un tas d'attributs et de ceux qui seraient perdus. Vous avez pour concaténer les noms nouvel attribut plus de celles existantes, ce qui est assez difficile de se rappeler comment le faire correctement. Pour faire simple, MakeNode va lire la propriété statique _ATTRS_2_UI et faire la concaténation pour vous. Il va concaténer toutes ces listes de la classe de tous et chacun dans la chaîne d'héritage de sorte à chaque niveau de chaque classe peut gérer ses propres attributs. En Spinner, nous avons:

  _ATTRS_2_UI: {
     BIND: valeur,
     SYNC: VALEUR
 }, 

MakeNode accepte à la fois un tableau de noms ou un nom d'attribut unique, comme dans ce cas.

La question se pose naturellement, pourquoi deux listes, une pour la liaison de l'autre pour la synchronisation? Très souvent, les SYNC tableau a moins d'entrées que le BIND liste et c'est parce que le modèle de la composante peut-être déjà la valeur par défaut même que l'attribut de configuration et il n'est pas nécessaire de faire une synchronisation initiale. So, if the default value for the value configuration attribute is an empty string and the <input> element in the template has no value attribute, then there is no need to sync them on initialization.

MakeNode will check for duplicate entries in any of these arrays. If any appear, it means that a class our component inherits from already handles this attribute and any new declaration would most likely overstep the _uiSetXxxx handler for it. Incidentally, MakeNode also checks for duplicate entries in _CLASS_NAMES , which can also cause conflict in some, though not all, circumstances. MakeNode will write a message to the log for any such error.

Conclusion

MakeNode provides a very simple template processor, with simple functionality that is highly integrated with the Widget foundation class. It also provides helper methods to create classNames to be used in the template and use those names to locate the nodes created. It also provides the means to hook into the events generated both by the UI and the component itself and associate each with a method. It does all these things, while taking care to respect the inheritance chain straight up to Widget and any level of classes you may define.

It does not provide for absolutely all possibilities, but covers a good range of them. Nevertheless, it does not preclude you from adding extra functionality. You might rarely have to write a bindUI or syncUI method if you use the glue provided by MakeNode, but you may do so, since MakeNode does not use them.

As a bonus to those who had the patience to read this far, I have also modified Anthony Pipkin's Button set of gallery components:

• button.js
• button.css
• button-group.js
• button-group.css
• background.png
• background-active.png
• icon-sprite.gif
• par exemple

The API docs can be found here .

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!

Changements YUI et Loader 3.4.0 pour les

In 3.4.0 we started the process of shifting some of Loader's logic around, to not only make it more performant, but to make it more robust and easier to use in other places (like on the server). We will be rolling out more changes in future revisions, but I wanted to take some time and explain what was changed, why it was changed and how it may impact developers. For the majority of use-cases, developers will notice nothing different, except that things are a little faster and their requirement downloads are a little smaller.

Seed File

The first thing I want to address is the YUI seed file. In previous versions of YUI, our seed file was very tiny and did not contain Loader or any of its meta-data. We've found that in the 90% use-case this was not as performant as we had hoped. The normal user includes the seed file then requests their modules, which in turn means that the seed needs to first fetch Loader, then calculate all of its dependencies, then fetch them all. We now feel that this extra http request is the wrong thing to do, so the new standard seed file contains Loader and its meta-data. Yes, this will make the initial request a little larger, but it will make the loading of modules that much faster since all of its meta-data requirements are now already on the page.

If you wish to use it the old way, you can just include the yui-base seed file instead. It contains everything that is needed to make YUI run in stand-alone mode plus it contains the ability to fetch Loader on demand. If you require even finer-grained dependencies, we have created a yui-core seed file that is exactly what the old yui-base seed was.

    /build/yui/yui-min.js //YUI Seed + Loader
    /build/yui-base/yui-base-min.js //Old YUI Seed with Loader fetch support
    /build/yui-core/yui-core-min.js //Old yui-base without Loader fetch support

It should be noted that these URLs are different than the previous URLs. Anyone that was using the yui/yui-base.js files need to repoint them to yui-core/yui-core.js . If you want the older way of loading the seed and fetching Loader, you would use the yui-base/yui-base.js seed file.

The other reasoning for this change is our roadmap for making YUI run in as many places as possible. The old seed file plus Loader in a single combo server request is all well and good if you have a combo server available in your application. But what about on the server? Or in an offline app on a mobile device? These places need to minimize file access while still getting the information they need.

Rollups

The next thing that we changed was removing rollups from the system and defaulting allowRollup to false in the Loader config. What does this mean to you? Well, hopefully nothing at all. Before I explain the impact of the change, let me explain the reasoning behind it. The primary reason is, again, performance, along with payload delivery. Take this example:

     Module A: requires event-a, event-b
     Module B: requires event-c, event-d

When you request both, the rollup logic prior to 3.4.0 used to determine that you should get the event rollup. Which actually meant that you were getting:

     event.a, event.b, event.c, event.d, event.e, event.f, event.g, event.h

You ended up with more on your page than you actually needed. By turning off the rollup support, YUI will now ask for only what you actually requested and nothing more. In most cases, you will not notice this . Module developers, may run into a situation where things that worked in the past may not work now. The reason for this is that they actually worked by accident before. Let me use a real world example: Dial .

In 3.3.0, Dial required this:

    requires: [
        'widget',
        'dd-drag',
        'substitute',
        'event-mouseenter', 
        'transition',
        'intl'
     ]

For the most part, Dial worked in 3.4.0, however keyboard support did not work. After doing some simple investigating, it turned out that the rollup support was actually requesting the entire Event rollup (which includes event-move and event-key). Without the rollup logic pulling in all of event, 3.4.0 Dial no longer had all of its requirements. Making Dial's requirements more specific and defining all of its actual dependencies properly makes it work as expected.

    requires: [
        'widget',
        'dd-drag',
        'substitute',
        'event-mouseenter',
        'event-move',
        'event-key',
        'transition',
        'intl'
     ]

For module developers, it is a best practice to make sure that your module requires exactly what it needs to function. Do not assume that an upstream module requirement is there. It's always better to make sure that you ask for what you need.

This also means that module requirements are more well defined. For example, datatype-date has Intl support built in. In previous versions you would access the Intl like this:

    Y.Intl.getAvailableLangs('datatype-date');

But since this module doesn't actually have a language (the datatype-date-format module does), this will fail. It needs to be more specific and actually ask for languages for the correct module:

    Y.Intl.getAvailableLangs('datatype-date-format');

Build File Explosion and Submodule Removal

After making this change, the next change we made was exploding the build directory and removing submodules from the core system. Submodule logic was not removed, only our meta-data structure was changed. This will provide backward compatibility for current installations.

Submodules in the core system caused a couple of issues that we needed to resolve. The first reason was performance. Each time Loader needed to calculate dependencies, it needed to walk the submodule/plugin structure of each module. Doing this thousands of times was hurting our performance during the Loader calculate routine. By removing support for submodules in the core system we saved tens of thousands of function calls and iterations.

Loader was changed so that if a use property in a module's meta-data defined more modules, it will use those modules instead of trying to load the original module. So, if you requested “ dd ” Loader would inspect “ dd “'s meta-data and see a use property that looks something like this:

    "dd-ddm-base,dd-ddm,dd-ddm-drop,dd-drag,dd-proxy,dd-constrain,dd-drop,dd-scroll,dd-drop-plugin"

In the core YUI seed file, we are also including what we are calling virtual rollups or aliases . These module definitions are exactly the same as the meta-data in Loader. This way you can include all the files exported from our Dependency Configurator and still use these rollups without having Loader present on the page. In future releases, we will be refining this approach even more.

After making this change, we then preceeded to explode our build files. In previous releases, the submodules determined the modules file path. Par exemple:

    "dd": {
        "submodules": {
            "dd-drag": 
            // Module data
         }
     }

In 3.3.0 when you built “dd”, the file structure looked something like this:

    /build/dd/dd-drag.js
    /build/dd/dd-ddm.js
    /build/dd/dd-drop.js

With the build system exploded in 3.4.0, “dd”'s build files now look like this:

    /build/dd-drag/dd-drag.js
    /build/dd-ddm/dd-ddm.js
    /build/dd-drop/dd-drop.js

This allowed us to remove the “path” property from all of our module meta-data as well, saving file size and reducing the logic required to assemble the modules url paths.

If you are including a pre-configured combo URL, you must recalculate your URL when you upgrade.

The downside to this change is that if you are including a combo URL of modules to “prep” your page you can not just change the version number and upgrade. You will need to revisit the Dependency Configurator and generate a new URL with new module structure.

The Future

I will be continuing to refine, refactor and maximize every aspect of our Loader and Seed strategy. These first steps were needed to aid in future changes that need to be made for not only our client-side strategy but also our server, command-line and mobile device strategies as well.

Trouver des conversations: Bloglines | technorati

Partager et prolonger: Conservez ce lien avec del.icio.us | Digg it! | reddit!