Blog Interface utilisateur Yahoo! (YUIBlog)

L'extension "MakeNode" Widget

Note de l'éditeur: Depuis que cet article a été publié à l'origine, le module de MakeNode a été publié à la Galerie YUI et a reçu quelques améliorations. S'il vous plaît se référer à l'article mis à jour, mise à jour: L'extension "MakeNode" Widget .

Dans mon précédent article, une recette pour un YUI 3 Application , j'ai montré un moyen d'utiliser Y.substitute comme un processeur de modèles très basique. 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 Widget qui est disponible sur mon site, appelé MakeNode . MakeNode n'est pas un processeur modèle générique et il ne se veut pas un. D'autre part, il est étroitement intégré avec le YUI Widget classe fondation, y compris les aides className et d'événements et d'internationalisation. Dans cet article, je vais prendre la Spinner exemple et le modifier à suivre les directives de mon article précédent et à utiliser MakeNode. Le composant Spinner modifié ( JS , CSS , sprites ) ainsi que d'un exemple sont disponibles sur mon site. Liens vers d'autres ressources peuvent être trouvées à la fin de cet article.

Extension de votre composant

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

  Y.Spinner = Y.Base.create (
      «Spinner»,
      Y.Widget,
      [Y.MakeNode],
      {
         / / Par exemple ... les membres
      },
      {
          / / Membres statiques
      }
 ); 

Vous pouvez ajouter MakeNode le long de tout nombre d'extensions appropriées pour Widget, comme 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é ou privé, 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és avec eux.

Définir le modèle de

La première chose que vous devrez normalement faire est de définir le modèle de votre appareil. 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 nommée _TEMPLATE et a déclaré le long des autres propriétés statiques de la classe, comme ATTRS . MakeNode utilisera ce modèle si rien d'autre est explicitement prévue. Le modèle est constitué de la version HTML brut, plus une série d'espaces réservés enfermés dans des accolades, constitués chacun 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 ….} la valeur de retour de la méthode donnée. Le code de traitement est suivie par le nom de méthode et un certain nombre d'arguments séparés par des espaces. Les chaînes doivent être entre guillemets doubles. Chiffres, booléens et null seront converties de chaîne à leurs propres types de données

• {c classNameKey} className CSS généré à partir du _CLASS_NAMES propriété statique

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

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

• {} toute autre valeur seront traitées comme Y.substitute fait.

Par exemple, {@ value} se traduira par this.get('value') tandis que {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 seront passés à la méthode donnée. Ces arguments peuvent être des nombres, null , true , false ou des chaînes entre guillemets. MakeNode sera les analyser et de les convertir à leurs propres types, ainsi {m myMethod 123.45 true “this is a string”} donnera lieu à l'appel this.myMethod(123.45, true, “this is a string”) de sorte que les deux premiers arguments sont convertis en leurs correctes types de données et de la chaîne peut contenir des espaces. Pour inclure un guillemet double, utilisez \\" , le double barre oblique inverse soit nécessaire car les scripts JavaScript va interpréter un seul et il se défausse avant qu'il arrive à MakeNode. Seuls les guillemets sont autorisés, MakeNode ne pas utiliser eval() de sorte que le parseur est limitée mais tout ce en toute sécurité. mais les chiffres, null , booléens et de chaînes entre guillemets sera ignoré.

Le {?} espace réservé est pratique à utiliser avec cases à cocher et des boutons radio. Il va produire la chaîne “checked” en fonction de la valeur de vérité du code d'instruction de traitement qui suit. Ainsi, <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> va produire une case à cocher marquée si le getLength méthode retourne rien, mais zéro. {?} sera accepté aucun des autres espaces réservés, même si elle n'a de sens que les trois premiers.

Pour le {c} espace réservé, nous avons besoin d'avoir un _CLASS_NAMES propriété définie.

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

La propriété _CLASS_NAMES

Avec le ATTRS et _TEMPLATE attributs statiques, nous pouvons définir une _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'] produiront le className “yui3-spinner-input” . Ces noms de classes sont stockées dans une propriété d'instance this._classNames . Le {c input} 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 quelconque de noms de classes, si vous les utiliser dans le modèle ou non. Vous pouvez encore atteindre ces noms de classes supplémentaires au sein de this._classNames . Le className est généré en utilisant l' yui3 préfixe suivi par la valeur de la NAME propriété statique se minuscules, puis la chaîne donnée dans _CLASS_NAMES (ce dernier ne sera pas mis en minuscules), le tout séparé par des tirets. Le _classNames hachage contiendra également les noms de classes pour la boundingBox et le contentBox , la première dans le cadre du "." clef et le second dans le cadre du “content” clé. Widget assigne à la boundingBox les noms de classes dérivées à partir des valeurs de la NAME propriété de chacune des classes dans la chaîne d'héritage, à commencer par yui3-widget . Magasins MakeNode dans this._classNames seulement le className plus au-dessus de la 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 produira classnames pour chacun d'eux et de les stocker dans this._classNames . Vous n'avez pas besoin d'inclure à chaque niveau des noms déjà déclaré dans les niveaux précédents. En fait, il vaut mieux que vous n'avez pas, puisque les noms de classes produites à chaque niveau, utilisez la valeur de la NAME propriété de ce niveau. Ainsi, dans SuperSpecialSpinner , {c input} , il en résultera “yui3-spinner-input” et non “yui3-superspecialspinner-input” et ainsi elle permet de conserver votre fichier CSS toujours valable.

Le {s} espace réservé

Widget possède une strings attribut de configuration définie, si elle n'est pas initialisée avec une valeur quelconque. Cet attribut est destiné à tenir les jeux qui sont visibles (ou, par l'intermédiaire d'un lecteur d'écran, lire) 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 consultés par ou lu à l'utilisateur doit toujours être placé dans la strings attribut. Le strings attribut contient une table de hachage où chaque texte est situé par sa clé. Le composant Spinner a des chaînes de caractères suivantes, que vous pouvez voir utilisés dans le modèle ci-dessus.

  cordes: {
     valeur: {
         entrée: "Appuyez sur la flèche haut / bas pour des incréments de mineurs, page up / down pour les augmentations importantes.",
         jusqu'à: «Increment»,
         vers le bas: "Diminuer"
     }
 }, 

La meilleure partie de cela, c'est que votre composant peut être localisé dans d'autres langues très facilement par les développeurs qui utilisent 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 des attributs de configuration strings de cette manière par défaut remplace les strings des valeurs avec celles du fichier de ressources de langue en utilisant le langage défini précédemment. Le {s} espace réservé d'accéder aux chaînes stockées dans le strings d'attribut, soit ceux par défaut ou ceux traduits, 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é. Toutefois, le premier ne peut accéder aux chaînes au plus haut niveau tandis que, par exemple, {@ strings.xxxx.yyyy.zzzz} vous permettra d'accéder à une chaîne de plus vers le bas.

Utilisation _makeNode dans renderUI

Nous utilisons le modèle pour créer le balisage de 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 de la transformation du modèle. Le _makeNode méthode retourne une instance de Y.Node qui peuvent être ajoutés ou insérés n'importe où ou vient de se tenir pour une utilisation ultérieure. Il ne retourne pas une chaîne, il 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 simple, il n'ya Spinner un modèle unique pour le widget entier, mais d'autres widgets peuvent nécessiter 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. La par exemple contient cette renderUI méthode:

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

Le premier appel à _makeNode retourne un Node par exemple stocké dans la variable fieldset . Le composant de l'échantillon est également étendu avec Y.ArrayList de sorte que le RADIO_TEMPLATE sera rempli avec des valeurs prises par les éléments stockés dans la liste du tableau et les nœuds résultants annexés à la fieldset avant d'être finalement annexée à la contentBox . Les espaces réservés spéciaux tels que {@} ou {p} se réfèrent toujours à des attributs ou des propriétés de l'objet principal. Les éléments imbriqués seront traitées comme Y.substitute le ferait.

Le Procédé _locateNodes

MakeNode fournit en outre un _locateNodes méthode qui vous permettra de localiser tous les éléments avec les noms de classes déclarées dans _CLASS_NAMES . Pour localiser des éléments spécifiques que vous pouvez passer un certain nombre de touches className, sinon, _locateNodes essaie tous. Pour chaque élément trouvé de chaque className, _locateNodes produira 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 le même className, _locateNodes retournera une référence à la première d'entre elles. Si un élément n'est pas trouvé, pas de 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 le long des lignes de _TEMPLATE et _CLASS_NAMES et c'est _EVENTS . _EVENTS contiendra un hash composé de touches de noms de classes, chacune contenant une table de hachage de types d'événements et les méthodes pour les gérer. Il est mieux expliqué par un exemple:

  _EVENTS: {
     '.': {
         clé: {
             fn: «_onDirectionKey»,
             args: ((Y.UA.opera) «vers le 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, c'est à dire les clés du hachage, identifier les éléments dont les événements nous é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é 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 les 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 pour y faire face. _EVENTS , étant une variable statique, n'a pas accès à this sorte qu'il ne peut pas prendre des références de fonction effectives, seul le nom de la méthode é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énement, vous pouvez fournir un objet avec des propriétés fn et args pour maintenir le nom de la fonction et les arguments supplémentaires, en cas de besoin.

MakeNode utilisera Node.delegate pour écouter les événements de ces éléments imbriqués, alors qu'il va utiliser Y.on pour écouter les événements de la boundingBox et le corps du document. (Remarque: l'écoute de la key cas sur n'importe quel élément imbriqué ne fonctionne qu'avec la version 3.4.0pr1 et ci-dessus, puisque la délégation de la key .. événement n'était pas disponible avant toutes les caractéristiques d'autres travaillent avec les versions précédentes ainsi)

Les _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ée séparément.

Le _ATTRS_2_UI propriété statique

Manifestations dans les deux sens, à partir de l'interface utilisateur pour la composante et de la composante de l'interface utilisateur. La première sont traitées par le _EVENTS propriété. Puis il ya les événements déclenchés par des changements de valeur d'attribut qui doivent être reflétés dans l'interface utilisateur. Comme je l'ai mentionné dans l'article précédent, quand il ya des effets secondaires de la modification d'un attribut de configuration, ils doivent être manipulés par des écouteurs d'événements de changement, non pas par le option 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 ce dernier, nous avons besoin d'attacher un écouteur d'événement, ce que nous faisons dans bindUI . Widget prévoit déjà un mécanisme pour faire aussi simple que cela, que j'ai décrit dans les commentaires à 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 doivent être initialement synchronisés puis écouté afin de garder l'interface utilisateur reflète les valeurs actuelles. Widget s'attend à ce que chacune de ces entrées d'avoir une méthode qui lui est associé, nommé d'après le nom de l'attribut préfixé par _uiSet avec le premier caractère du nom de l'attribut convertis en majuscules d'avoir le nom de méthode dans le cas de chameau bon. Ainsi, si "value" a été inscrit dans l'une des _UI_ATTRS tableaux (dans les deux SYNC ou BIND ), Widget s'attendrait à trouver un _uiSetValue méthode. Cette méthode recevra deux arguments, le value définie et src du changement. C'est le code de notre Spinner _uiSetValue méthode:

  _uiSetValue: la fonction (valeur, src) {
     if (src === UI) {
         retour;
     }
     this._inputNode.set (VALEUR, this.get (Formatter) (valeur));
 }, 

Tous les identifiants en majuscules que vous voyez dans ce morceau de code correspondent à des constantes de chaîne déclarée ailleurs, pour permettre au compresseur YUI à mieux faire son travail. La méthode, essentiellement, définit la value l'attribut HTML dans le <input> case pour l'ensemble la 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. C'est pour éviter les boucles infinies. Si l'utilisateur entre quelque chose dans la boîte d'entrée, sa valeur serait aller dans le value attribut de configuration qui serait alors le feu à un 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 l'ensemble du processus à nouveau. Ainsi, dans _uiSetValue , si nous savons que le changement vient de l'interface utilisateur, nous ne faisons rien et ainsi de briser la boucle. Cependant, cela nécessite un autre morceau de code à un autre. Dans l'écouteur pour l'événement DOM, lorsque nous avons créé l'attribut de configuration, nous utilisons le troisième argument facultatif à définir, comme ceci:

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

Il est à nous de s'assurer que les changements à venir à partir de l'interface utilisateur sont signalés ainsi et puis vérifiez que même drapeau pour éviter les boucles.

Avec tout cela dit, je n'ai pas encore parlé de la propriété statique _ATTRS_2_UI mentionné dans le titre de cette section. Comme les commentaires dans mes spectacles article précédent (à travers les maladresses que j'ai faites dans ces entreprises), en s'assurant que tous les attributs qui affectent l'interface utilisateur sont correctement répertoriés est un peu désordonné. Vous ne devriez jamais initialiser _UI_ATTRS à partir de zéro depuis Widget répertorie déjà tout un tas d'attributs et ceux-ci seront perdues. Vous devez concaténer les noms des attributs nouveaux sur celles qui existent déjà, ce qui est un peu difficile de se rappeler comment le faire correctement. Pour faire simple, MakeNode lira des extraits de la propriété statique _ATTRS_2_UI et faire concaténation pour vous. Il sera concaténer tous ces listes de la classe chaque 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 acceptera à la fois un tableau de noms ou un nom d'attribut unique, comme dans ce cas.

La question se pose naturellement, pourquoi deux listes, l'une pour la liaison de l'autre pour la synchronisation? Très souvent, le SYNC tableau a moins d'entrées que le BIND liste et c'est parce que le modèle pour le composant 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. Donc, si la valeur par défaut pour la value l'attribut de configuration est une chaîne vide et la <input> élément dans le modèle n'a pas de value d'attribut, alors il n'ya pas besoin de les synchroniser à l'initialisation.

MakeNode va vérifier les entrées en double dans l'une de ces tableaux. Si tout semble, cela signifie qu'une classe hérite de notre composant gère déjà cet attribut et toute nouvelle déclaration dépasserait probablement le _uiSetXxxx gestionnaire pour lui. Par ailleurs, MakeNode vérifie également pour les entrées en double dans _CLASS_NAMES , qui peuvent aussi causer des conflits dans certains pays, mais pas tous, les circonstances. MakeNode va écrire un message dans le journal pour une telle erreur.

Conclusion

MakeNode fournit un processeur modèle très simple, avec des fonctionnalités simples qui est fortement intégrée à la classe Widget fondation. Il fournit également des méthodes d'assistance pour créer classnames à être utilisé dans le modèle et d'utiliser ces noms pour localiser les noeuds créés. Il fournit également les moyens pour accrocher les événements générés à la fois par l'interface utilisateur et le composant lui-même et d'associer chacun avec une méthode. Il fait toutes ces choses, tout en prenant soin de respecter la chaîne d'héritage droite jusqu'à Widget et le niveau des classes que vous pouvez définir.

Il ne prévoit pas absolument toutes les possibilités, mais couvre une bonne gamme d'entre eux. Néanmoins, il ne vous empêche pas d'ajouter des fonctionnalités supplémentaires. Vous pourriez ont rarement pour écrire un bindUI ou syncUI méthode si vous utilisez de la colle fournie par MakeNode, mais vous pouvez le faire, puisque MakeNode ne pas les utiliser.

Comme un bonus à ceux qui avaient la patience de lire le jeu de boutons de cette mesure, j'ai aussi modifié Anthony Pipkin de composants galerie:

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

La documentation de l'API peuvent être trouvés ici .

Trouver des conversations: bloglines | technorati

Partagez et étendre: Créer un signet avec del.icio.us | digg it! | reddit!