Blog Interface utilisateur Yahoo! (YUIBlog)

Mise à jour: L'extension "MakeNode" Widget

Note de l'éditeur: Cet article a été publié à l'origine plus tôt cette année . Depuis lors, le module de MakeNode a été publié à la Galerie YUI et a reçu quelques améliorations. L'article d'aujourd'hui reflète tous les dernières modifications apportées à MakeNode.

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 la galerie de YUI, 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. MakeNode est disponible en tant que composant la galerie ainsi que la modification de Spinner composant et le par exemple qui sera utilisé dans cet article .

Extension de votre composant

Pour charger MakeNode vous devez inclure le module dans votre YUI().use() déclaration en utilisant le nom 'gallery-makenode' ou, si la définition d'un module via YUI.add() , il liste en tant que requires tableau. 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 susceptibles d'être utilisés par le développeur, _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. N'oubliez pas de cocher la case "Afficher Protégé" option lors de la visualisation de la documentation de l'API .

Définir le modèle

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.

• {c classNameKey} className CSS généré à partir du _CLASS_NAMES propriété statique (voir La propriété _CLASS_NAMES section ci-dessous)

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

• {? condition valueIfTrue valueIfFalse } un peu comme le ?: opérateur de JavaScript, évalue à valueIfTrue si la condition est truish, valueIfFalse autrement.

• {1 condition valueIfOne valueIfMore } utilisée pour produire singulier / pluriel des mots sur la base de la valeur de la condition.

• {} 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'] .

Lorsque des espaces réservés avoir des arguments, comme {m} , {?} et {1} , les chaînes doivent être entre guillemets doubles. Numéros, les booléens et null (tous les guillemets) sera analysé à leurs propres types de données. Les espaces réservés peuvent être imbriquées. Le {?} et {1} espaces réservés contiennent généralement un espace réservé imbriqué pour l'état et peut-être de leurs valeurs, par exemple:

  {P} {1 qté {p} qté «unité» des «unités»} 

Si la propriété qty est de 1, il sera évalué à "1 unit" , pour 2 ou plus, il sera de retour "2 units" et ainsi de suite. Une version plus élaborée face à zéro serait:

  {?  {P} qté "{p} {1 qté {p} qté« unité »des« unités »}" "none"} 

Notez que le résultat du traitement des espaces réservés intérieures, si une chaîne, doit être enfermé dans son propre ensemble de citations.

Pour inclure un guillemet double à l'intérieur une chaîne entre guillemets, 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() afin l'analyseur est limitée, mais en toute sécurité. Tout sauf des numéros, null , booléens et de chaînes entre guillemets sera ignoré.

Le {?} espace réservé est également très pratique à utiliser avec cases à cocher et des boutons radio. Il peut être utilisé pour 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} "checked" ""}/> <input type="checkbox" {? {m getLength} "checked" ""}/> va produire une case à cocher marquée si le getLength méthode retourne rien, mais zéro.

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

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

La propriété _CLASS_NAMES

Avec le ATTRS et _TEMPLATE propriétés statiques, nous pouvons définir une _CLASS_NAMES propriété statique 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" . J'appelle les chaînes répertoriées dans _CLASS_NAMES , tels que 'input' , les «touches className", car ils peuvent être utilisé comme une clé pour faire référence à l'className réelle ou les éléments contenant ces noms de classes, comme nous le verrons plus tard.

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 , le premier en vertu de la "boundingBox" clé et la seconde 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 le module est chargé WidgetStdMod, MakeNode générera également des entrées pour son HEADER , BODY et FOOTER sections avec ces mêmes touches, qui sont aussi les constantes définies dans ce même module.

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 presque comme utiliser {@ strings.xxxx} sauf que les chaînes de remplacement localisées peuvent avoir des espaces réservés qui seront traitées ultérieurement. Ceci est important pour les traductions depuis l'ordonnance syntaxique varie d'une langue à ce qui permet de reformuler le texte, y compris ses espaces réservés pour convenir à n'importe quelle langue. Les chaînes peuvent également être accessibles à l'aide {@ strings.xxxx.yyyy.zzzz} , ce qui permettra l'accès à des chaînes imbriquées plus bas et permettra d'éviter les substitutions supplémentaires. Les accolades peuvent être inclus dans un texte en utilisant {LBRACE} et {RBRACE} comme des espaces réservés.

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. (Si vous avez besoin d'une chaîne et non pas un nœud, vous pouvez utiliser la _substitute méthode, qui exige que vous passez dans un modèle.)

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));
     }, Ce);
     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.

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: {
     entrée: le «changement», / / ​​appels this._afterInputChange
     boundingBox: [
         {
             Type: «clé»,
             fn: «_onDirectionKey ', / / ​​appels this._onDirectionKey
             args: ((Y.UA.opera) «vers le bas:":!? "presse:") + "38, 40, 33, 34"
         },
         'MouseDown' / / appels this._afterBoundingBoxMousedown
     ],
     document: «mouseup ', / / ​​appels this._afterDocumentMouseup,
     Y: «broadcastingObject: unEvenement '/ / appels de cette [" _afterYBroadcastingObject: unEvenement "]
 }, 

_EVENTS est un objet (une table de hachage) avec n'importe quel nombre d'entrées. Les noms des propriétés, c'est à dire les clés du hachage, identifier les nœuds dont les événements nous écouter. Ils sont les clés className mêmes définis dans _CLASS_NAMES . Il ya plusieurs touches spéciales supplémentaires:

• "boundingBox" fera référence à la boîte englobante lui-même.

• "document" se réfère au document contenant ce widget.

• "THIS" fait référence à la widget lui-même

• "Y" se réfère à l' Y exemple.

Si le Widget a été étendu avec WidgetStdMod ainsi, les touches HEADER , BODY et FOOTER fera référence à ces articles, car ils seront disponibles dans le _classNames hachage. JavaScript n'a pas besoin des clés pour être cités s'ils sont des identifiants valides si aucune de ces réponses doivent être cité.

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 "document" identifiant échouera.

Pour chacun de ces éléments est un identificateur d'événement ou d'un tableau d'identificateurs d'événement. Un événement peut être identifié par le type d'événement à écouter ou à un objet avec plus de détails. Par défaut, MakeNode sera utiliser comme un auditeur d'une méthode appelée en utilisant le "_after" préfixe suivi par l'identifiant de l'élément avec son premier caractère majuscule suivie par le type d'événement avec son premier caractère en majuscule. Le bloc de code ci-dessus montre les méthodes appelées pour chaque événement.

Un identificateur d'événement peut aussi être un objet avec des propriétés type , fn , et args . Le type est obligatoire et indique le type d'événement d'être écouté. Le fn propriété donne le nom de la méthode qui doit écouter l'événement en évitant ainsi la désignation automatique. Depuis _EVENTS est une propriété statique, il n'a pas accès à this sorte qu'il ne peut pas prendre une référence à la méthode, seul son nom. Le args argument peut être utilisé pour passer des arguments supplémentaires à l'appelant comme avec la key un événement qui nécessite une spécification touches.

MakeNode utilise Node.delegate écouter les événements sur les éléments dans le boundingBox , tandis qu'il utilise Node.after écouter les événements à partir du boundingBox et le corps du document. Il va utiliser this.after pour écouter les événements dans le cadre du THIS clé et Y.after pour les auditeurs énumérés sous la Y clé. Tous les événements sont écoutés à l'aide après des écouteurs d'événements, car ils visent à rendre le widget de réagir aux événements, de ne pas filtrer le comportement de l'objet qui déclenche eux afin, en aucun cas ces événements peuvent être empêchée ou arrêtée. (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 cas 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, que nous ne le feraient normalement en 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 de 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. Ne utiliser l'identificateur src lors de la création de la valeur de l'attribut, et non pas source ce qui ne sera pas reconnu.

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? SYNC est utilisé pour la première fois autour, après les renderUI et bindUI méthodes, si elles existent, sont appelés et avant syncUI tandis que ceux énumérés dans BIND sera lié à les attributs correspondants pour les modifications ultérieures. 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.

Attributs répertoriés dans BIND auront leurs _uiSet Xxxx méthodes appelées dans n'importe quel ordre, comme les attributs peuvent être mis dans n'importe quel ordre. Attributs répertoriés dans SYNC sera appelée une fois dans l'ordre dans lequel ils sont répertoriés avec ceux des ancêtres devant leurs héritiers, si l'on est dépendant d'un autre (ce qui ne devrait pas), l'ordre peut être important.

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 _uiSet Xxxx 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.

La propriété _PUBLISH

Enfin, le _PUBLISH propriété statique énumère les événements qui doivent être publiés. Il contient un hachage en utilisant le nom de l'événement que ses clés et un littéral d'objet d'attributs de configuration que ses valeurs. Il publiera tous les événements répertoriés dans un de ces biens dans toute la chaîne d'héritage. Le nom même événement peut être publié dans une classe et dans n'importe quelle classe qui hérite de lui, ce qui rendra les attributs de configuration de ceux plus tard remplacer les dans les plus anciens. Par exemple, vous voudrez peut-être faire un événement de diffusion existant dans le monde. Tout comme avec le _EVENTS la propriété, depuis _PUBLISH est une propriété statique, sans accès à this , lors de la spécification des fonctions, c'est le nom de la méthode, comme une chaîne, qui doit être donné.

Conclusion

MakeNode fournit un processeur modèle très simple, avec des fonctionnalités qui est étroitement intégrée avec 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 et consulter les nœuds 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 de la galerie et fait un accordéon et composants TimeSpinner, tous disponibles dans la Galerie .

À propos de l'auteur: Daniel Barreiro (nom d'écran Satyam) a été autour depuis un certain temps. L'ENIAC a été désactivé le jour avant sa naissance, de sorte qu'il a manqué cela, mais il n'a pas manqué beaucoup depuis. Il a eu une chance de cartes perforées, le programme de 6502 jetons (souvenez-vous de l'Apple II?), De posséder une. TRS-80 et voir quelques morceaux fantastiques de l'équipement d'exploitation dans son pays natal, l'Argentine, qui auraient pu être dans les musées d'ailleurs Quand la mondialisation a ouvert les portes du monde, qui était alors son à peine utilisable en anglais (plus un diplôme en génie électrique) a mis sur le cheminement de carrière qui s'est terminée dans un emploi de 5 ans dans le dos Bay Area dans les jours de NCSA Mosaic. Totalement intrigué par les gribouillis amusants un ami de son écrit dans son éditeur de texte, plein de <'s et>' s, il a fini par apprendre beaucoup de choses sur le monde de l'ingénierie frontend. Il a été un long voyage depuis COBOL et Fortran. Maintenant, il vit tout à fait heureux en semi-retraite dans le proche littoral méditerranéen à Barcelone, Espagne.

Trouver des conversations: bloglines | technorati

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