El "MakeNode" Widget de Extensión

08 de julio 2011 a las 2:11 pm por Satyam | En Desarrollo | 6 Comentarios

En mi anterior artículo, una receta para un YUI 3 Aplicación , me mostró una manera de utilizar Y.substitute como un procesador de plantilla muy básica. La idea tomó vida a partir de ahí, con las sugerencias de la gente en el canal de IRC # yui, y me hizo una extensión de Widget que está disponible en mi sitio, llamado MakeNode . MakeNode no es un procesador de plantilla genérica y no se entiende como una sola. Por otro lado, que está estrechamente integrado con el YUI Widget clase base, incluyendo ayudantes className y eventos y la internacionalización. En este artículo, voy a tomar el Spinner ejemplo y modificarlo para que siga las directrices de mi artículo anterior y de utilizar MakeNode. El componente de Spinner modificados ( JS , CSS , sprites ), así como un ejemplo están disponibles en mi sitio. Vínculos a recursos adicionales se pueden encontrar al final de este artículo.

La ampliación de su componente

Una vez que se carga MakeNode, es necesario incluir el módulo en su YUI().use() declaración utilizando el nombre de 'makenode' . Entonces, para ampliar su widget, que lista en el tercer argumento a Y.Base.create() , de esta manera:

  Y. Spinner = Y.Base.create (
      'Spinner',
      Y. Widget,
      [Y. MakeNode]
      {
         / / Los miembros de instancias ...
      },
      {
          / / Los miembros estáticos
      }
 ); 

Usted puede agregar MakeNode a lo largo de cualquier número de extensiones adecuadas para Widget, como WidgetParent, WidgetChild, WidgetStdMode, etc MakeNode añade dos métodos de protección, _makeNode y _locateNodes, y se lee de varias propiedades estáticas, si lo encuentra.

Todos los miembros de esta extensión son protegidos o privados, ya que están destinados a ser utilizados por el desarrollador de componentes y no por el ejecutor con los componentes, que no debe ser molestado con ellos.

La definición de la plantilla

La primera cosa que normalmente va a hacer es definir la plantilla para su componente. Para el Spinner, nuestra plantilla será:

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

La plantilla por defecto suele ser llamado _TEMPLATE y declaró a lo largo de las otras propiedades estáticas de la clase, como ATTRS . MakeNode usará esta plantilla si nada se prevé explícitamente. La plantilla está hecha de HTML sencillo, además de una serie de marcadores de posición encerrada entre paréntesis, cada uno compuesto de un solo personaje (el código de procesamiento) y seguido por uno o más argumentos. Los marcadores de posición y lo que producen son:

  • {@ attributeName} valor de configuración de atributos

  • {p propertyName} valor de instancia de la propiedad

  • {m methodName arg1 arg2 ….} valor de retorno del método que se indica. El código de procesamiento es seguido por el nombre del método y cualquier número de argumentos separados por espacios en blanco. Las cadenas deben ir entre comillas dobles. Números, booleanos y null se convierte de cadena a los tipos de datos adecuados

  • {c classNameKey} CSS className generados a partir de la _CLASS_NAMES propiedad estática

  • {s key} de la cadena de strings de atributos, utilizando key como el atributo secundario.

  • {? other placeholder } Produce la cadena de checked que el resultado de la transformación del resto del marcador de posición es verdad.

  • {} cualquier otro valor se tratará como Y.substitute hace.

Por ejemplo, {@ value} se traducirá en this.get('value') , mientras que {p value} se traduce en this['value'] .

El {m} marcador de posición es un poco más complejo. El primer argumento después de la m código de procesamiento es el nombre del método y el resto de los argumentos, todos separados por espacios en blanco, que se pasarán al método especificado. Esos argumentos pueden ser números, null , true , false o cadenas entre comillas dobles. MakeNode magia, los analizará y convertirlos a su tipo adecuado, por lo tanto {m myMethod 123.45 true “this is a string”} dará lugar a llamar a this.myMethod(123.45, true, “this is a string”) a fin de que los dos primeros argumentos se convierten en sus tipos de datos correctos y la cadena puede contener espacios. Para incluir una comilla doble, use \\" , la doble barra invertida que se requiera debido a JavaScript interpretará a uno solo y lo elimina antes de llegar a MakeNode. Sólo se permiten las comillas dobles, MakeNode no utiliza eval() por lo que el intérprete se limita pero seguro. Cualquier cosa, pero los números, null , booleanos y dobles cadenas entre comillas será ignorado.

El {?} marcador de posición es útil para usar con casillas de verificación y botones de radio. Se produce la cadena “checked” en función del valor de verdad del código de instrucción de procesamiento que sigue. Por lo tanto, <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> se produce una casilla marcada si getLength método devuelve nada, pero a cero. {?} aceptará cualquiera de los otros marcadores de posición, a pesar de que sólo tiene sentido con las tres primeras.

Para el {c} marcador de posición, tenemos que tener un _CLASS_NAMES propiedad definida.

Marcadores de posición se pueden añadir otras para MakeNode agregándolos a la _templateHandlers hash.

La propiedad _CLASS_NAMES

Junto con el ATTRS y _TEMPLATE atributos estáticos, podemos definir una _CLASS_NAMES propiedad que apunta a una matriz de cadenas. Cada una de estas cadenas se utilizan para generar un nombre de clase. Así _CLASS_NAMES: ['input'] producirá el className “yui3-spinner-input” . Los classNames se almacenan en una instancia de propiedad this._classNames . La {c input} marcador de posición en la plantilla anterior será reemplazada por “yui3-spinner-input” .

Usted puede utilizar el _CLASS_NAMES propiedad para generar cualquier número de classNames, si usted los utiliza en la plantilla o no. Se puede acceder a los classNames adicionales desde dentro this._classNames . El nombre de clase se genera utilizando el yui3 prefijo seguido por el valor de la NAME propiedad estática convertido en minúsculas, a continuación, la cadena dada en _CLASS_NAMES (este último no se convertirá en minúsculas), todos separados por guiones. El _classNames hash también contendrá el classNames para el boundingBox y el contentBox , el primero bajo el "." clave y el segundo bajo el “content” clave. Widget asigna a la boundingBox la classNames derivan de los valores de la NAME propiedad de cada una de las clases en la cadena de herencia, a partir de yui3-widget . Tiendas MakeNode en this._classNames sólo el nombre de clase de nivel más alto de la boundingBox .

Si un componente es el nivel de distancia de Widget, al igual que SuperSpecialSpinner la herencia de SuperSpinner que hereda de Spinner que hereda de Widget, y si alguno o todos ellos tienen _CLASS_NAMES propiedades definidas, MakeNode producirá classNames para todos ellos y guardarlos en this._classNames . No es necesario incluir en cada nivel de los nombres ya han declarado en los niveles anteriores. De hecho, es mejor que no ya que el classNames producido en cada nivel se utilizará el valor de la NAME propiedad de ese nivel. Así, en SuperSpecialSpinner , {c input} todavía se traducirá en “yui3-spinner-input” y no “yui3-superspecialspinner-input” y así conseguir que su archivo CSS sigue siendo válida.

El marcador de posición {s}

Widget tiene strings atributo de configuración definida, aunque no se ha inicializado con cualquier valor. Este atributo tiene la intención de mantener las cadenas que son visibles (o, a través de lectores de pantalla, para leer) el usuario. Es importante que no se incluyen las cadenas visibles directamente en la plantilla. Esto no es un requisito de MakeNode - nunca ha sido una buena idea en absoluto. Todas las cadenas que van a ser vistos por o leer para el usuario siempre debe ser colocado en la strings de atributos. La strings atributo contiene un valor hash que se encuentra cada texto individual por su clave. El componente de Spinner tiene la siguientes cadenas de texto, que se puede ver utilizado en la plantilla anterior.

  cadenas: {
     valor: {
         de entrada: ". Pulse la flecha arriba / abajo para incrementos menores, en la página arriba / abajo para incrementos importantes",
         así: "incremento",
         abajo: "decremento"
     }
 }, 

La mejor parte de esto es que el componente se puede localizar a otros idiomas muy fácilmente por los desarrolladores que utilizan el componente. Cuando se crea una instancia de Spinner, puede hacer:

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

Al establecer el atributo de configuración strings de esta manera sustituye el valor por defecto strings con los valores del archivo de recursos del lenguaje usando el lenguaje previamente definidos. La {s} marcador accede a la cadenas almacenadas en la strings de atributos, ya sea la falta de pago o los traducidos, si se establece. La {s xxxx} marcador de posición es, de hecho, nada más que un acceso directo al {@ strings.xxxx} marcador de posición. Sin embargo, los primeros sólo pueden acceder a las cadenas en el nivel superior, mientras que, por ejemplo, {@ strings.xxxx.yyyy.zzzz} le permitirá acceder a una cadena de más abajo.

Utilizando _makeNode en renderUI

Usamos la plantilla para crear el marcado en el componente. Para ello, podemos decir que es MakeNode _makeNode método, de esta manera:

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

Esto llenará en el contentBox de nuestro widget con el marcado del procesamiento de la plantilla. El _makeNode método devuelve una instancia de Y.Node , que se pueden añadir o insertar en cualquier lugar o que acaba de celebrarse para su uso posterior. No devuelve una cadena, se produce un Node instancia.

El _makeNode método toma dos argumentos opcionales: una referencia a una plantilla y un objeto de rellenar los marcadores de posición, como Y.substitute hace. En nuestro ejemplo Spinner simples hay una sola plantilla para el widget de conjunto, sino de otros controles podría requerir partes y piezas hechas de varias plantillas. En ese caso, que generalmente se llama _makeNode sin argumentos de la parte principal y lo llaman de nuevo con diferentes plantillas para rellenar las partes extra. El ejemplo contiene este renderUI método:

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

La primera llamada a _makeNode devuelve un Node instancia almacenada en la variable de fieldset . El componente de la muestra se extiende también a Y.ArrayList por lo que el RADIO_TEMPLATE estará lleno de valores tomados de los elementos almacenados en la lista de arreglos y los nodos resultantes se añade al fieldset antes de que sea anexado al contentBox . Los marcadores de posición especiales como {@} o {p} todavía se refieren a los atributos o propiedades del objeto principal. Los elementos anidados será procesado al igual que Y.substitute haría.

El método _locateNodes

MakeNode proporciona además un _locateNodes método que trate de localizar todos los elementos con los classNames declarado en _CLASS_NAMES . Para localizar los elementos específicos que puede pasar cualquier número de llaves className, de lo contrario, _locateNodes trata de todos ellos. Para cada elemento que se encuentra cada uno de className, _locateNodes producirá una propiedad de instancia privada que utiliza el prefijo de subrayado seguido por el nombre de clave y el “Node” sufijo. Por lo tanto, en nuestro ejemplo Spinner, _locateNodes generará las propiedades _inputNode , _upNode y _downNode . Si varios elementos tienen la misma className, _locateNodes devolverá una referencia a la primera de ellas. Si un elemento no se encuentra, no hay ninguna variable se creará.

En el componente de Spinner usamos _locateNodes después de crear el marcado:

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

La propiedad _EVENTS estática

Una de las propiedades más se puede definir en la línea de _TEMPLATE y _CLASS_NAMES y que es _EVENTS . _EVENTS contendrá un hash formado por teclas nombre de la clase, cada uno con un valor hash de los tipos de eventos y los métodos para manejar. Que se explica mejor con un ejemplo:

  _EVENTS: {
     '.': {
         clave: {
             FN: "_onDirectionKey,
             args: ((Y.UA.opera) "hacia abajo":? "prensa") + "38, 40, 33, 34"
         },
         MouseDown: "_onMouseDown '
     },
     '..': {
         MouseUp: "_onDocMouseUp '
     },
     entrada: {
         cambio: "_onInputChange '
     }
 }, 

_EVENTS es un objeto (un hash) con cualquier número de propiedades. Los nombres de las propiedades, es decir, las llaves del hash, identificar los elementos que los acontecimientos nos va a escuchar. Son los mismos identificadores usados ​​en _CLASS_NAMES . Hay dos claves muy especial "." y ".." . Mientras que las teclas className se refieren a elementos anidados en el contentBox , el "." clave se refiere a la boundingBox mismo tiempo ".." se refiere al documento que contiene este widget. Pensar en ellos como hacer un chdir comando cuando se encuentra en el boundingBox nivel. El _EVENTS propiedad se entregarán a partir del renderUI , bindUI y syncUI métodos han sido llamados para que el flash se espera que ya esté insertada en el cuerpo del documento, de lo contrario el ".." se producirá un error.

Cada una de las entradas en _EVENTS es un objeto, además, que utiliza el tipo de evento como su clave y el nombre de un método de instancia para manejarlo. _EVENTS , siendo una variable estática, no tiene acceso a this por lo que no puede tomar referencias reales de la función, sólo el nombre del método de detector de eventos. Algunos tipos de eventos necesitan argumentos adicionales, como la key del evento. En ese caso, en lugar de proporcionar el nombre del controlador de eventos puede proporcionar un objeto con propiedades fn y args para sostener el nombre de la función y los argumentos adicionales, cuando sea necesario.

MakeNode utilizará Node.delegate para escuchar a los acontecimientos de los elementos anidados, mientras que utilizará Y.on para escuchar a los eventos del boundingBox y el cuerpo del documento. (Nota: escuchar a los key eventos en cualquier elemento anidado sólo funciona con 3.4.0pr1 versión y la anterior, ya que la delegación de la key .. evento no estaba disponible antes de todas las características de la otra funciona con versiones anteriores también)

El _EVENTS declaraciones son acumulativos cuando los componentes de heredar el uno del otro. Cada clase en la cadena de herencia tendrá su propia _EVENTS declaración procesan por separado.

La propiedad _ATTRS_2_UI estática

Eventos en ambos sentidos, desde la interfaz de usuario para el componente y del componente de la interfaz de usuario. Los primeros son manejados por el _EVENTS propiedad. Luego están los eventos activados por cambios de valor de atributo que deben reflejarse en la interfaz de usuario. Como ya he mencionado en el artículo anterior, cuando hay algún efecto secundario de cambiar un atributo de configuración, que debe ser manejado por los detectores de eventos cambio, y no por el opcional setter método del atributo, que sólo debería ocuparse de normalizar el valor que se establece. La interfaz de usuario debe reflejar el estado de los atributos de configuración, por primera vez en syncUI , cuando se inicia y luego en cada evento de cambio de atributo. En este último caso, es necesario conectar un detector de eventos, lo que hacemos en bindUI . Widget ya proporciona un mecanismo para hacer así de simple, que se describe en los comentarios al artículo anterior.

Widget utiliza la propiedad de instancia _UI_ATTRS que contiene un objeto con dos propiedades más, SYNC y BIND . Cada uno de estos es una matriz con los nombres de los atributos de configuración que inicialmente sincronizados y luego escuchó el fin de mantener la interfaz de usuario que refleja los valores actuales. Widget espera que cada una de las entradas para tener un método asociado a él, llamado así por el nombre del atributo con el prefijo _uiSet con el primer carácter del nombre del atributo convertido en mayúsculas para que el nombre del método en el caso de camello adecuada. Por lo tanto, si "value" fue incluido en ninguno de los _UI_ATTRS matrices (en cualquiera de SYNC o BIND ), Widget esperaría encontrar una _uiSetValue método. Este método recibe dos argumentos, el value se establece y el src del cambio. Este es el código para nuestro Spinner _uiSetValue método:

  _uiSetValue: function (valor, src) {
     if (src === IU) {
         return;
     }
     this._inputNode.set (VALUE, this.get (formateador) (valor));
 }, 

Todos los identificadores en mayúsculas que se ve en esta pieza de código se corresponden con las constantes de cadena declarada en otro, para permitir que el compresor YUI para hacer su trabajo mejor. El método, básicamente, establece el value de atributos HTML en los <input> caja para el conjunto de un nuevo valor, después de ser formateado. La referencia a la caja de texto fue proporcionado por _locateNodes . El src argumento es inicialmente revisa para ver si se establece en el valor de cadena 'ui' . Si esto es así, no se tomarán medidas. Esto es para evitar bucles infinitos. Si el usuario introduce algo en el cuadro de entrada, su valor sería entrar en el value atributo de configuración que luego un incendio valueChange evento, que se _uiSetValue llamada, la cual, si no se controla, entonces iría a cambiar el valor de la casilla de entrada, que daría lugar a todo el proceso otra vez. Así, en _uiSetValue , si sabemos que el cambio viene de la interfaz de usuario, no hacemos nada y así romper el ciclo. Sin embargo, esto requiere de otra pieza de código en otros lugares. En el detector para el evento DOM, cuando se establece el atributo de configuración, se utiliza el tercer argumento opcional para establecer, de esta manera:

  _afterValueChange: function (ev) {
     this.set (VALUE, ev.newVal, {src: la interfaz de usuario});
 } 

Nos corresponde a nosotros para asegurarse de que los cambios vienen de la interfaz de usuario se marcan así y luego comprobar que una misma bandera para evitar bucles.

Con todo esto dicho, no he mencionado todavía la propiedad estática _ATTRS_2_UI mencionado en el encabezamiento de esta sección. Como los comentarios en mi artículo anterior muestra (a través de los errores que hice en ellas), asegurándose de que todos los atributos que afectan a la interfaz de usuario están correctamente la lista es un poco desordenado. Nunca se debe iniciar _UI_ATTRS a partir de cero desde Widget ya las listas de un montón de atributos y los que se perdería. Usted tiene que concatenar los nombres de nuevos atributos en los ya existentes, que es algo difícil de recordar cómo hacerlo bien. Para hacerlo simple, MakeNode leerá de la propiedad estática _ATTRS_2_UI y hacer que la concatenación para usted. Se concatena todas las listas como de la clase de todos y cada uno en la cadena de herencia que en cada nivel de cada clase puede manejar sus propios atributos. En Spinner, tenemos:

  _ATTRS_2_UI: {
     BIND: VALOR,
     SYNC: VALOR
 }, 

MakeNode se aceptan una serie de nombres o un nombre de atributo, como en este caso.

La pregunta surge naturalmente, ¿por qué dos listas, una para la unión del otro para sincronizar? Muy a menudo el SYNC matriz tiene menos puntos que el BIND lista y esto se debe a la plantilla para el componente que ya tenga el valor por defecto mismo como el atributo de configuración y no hay necesidad de hacer una primera sincronización. Por lo tanto, si el valor predeterminado para el value atributo de configuración es una cadena vacía y la <input> elemento en la plantilla no tiene ningún value de atributo, entonces no hay necesidad de sincronizar en la inicialización.

MakeNode buscará entradas duplicadas en cualquiera de estos arreglos. Si aparecen, significa que un componente de nuestra clase hereda de que ya maneja este atributo y toda nueva declaración, que sobrepasan más probable es que el _uiSetXxxx controlador para ello. Por cierto, MakeNode también comprueba las entradas duplicadas en _CLASS_NAMES , que también puede causar conflictos en algunos, aunque no todas, las circunstancias. MakeNode a escribir un mensaje en el registro de dicho error.

Conclusión

MakeNode ofrece un procesador de plantilla muy simple, con un funcionamiento sencillo que está muy integrada con la clase base Widget. También ofrece métodos de ayuda para crear classNames para ser utilizado en la plantilla y el uso de esos nombres para localizar los nodos creados. También proporciona los medios para engancharse a los eventos generados tanto por la interfaz de usuario y el propio componente y asociar cada uno con un método. Que hace todas estas cosas, teniendo cuidado de respetar la cadena de herencia hacia arriba para Widget y cualquier nivel de las clases se pueden definir.

Que no contempla absolutamente todas las posibilidades, sino que abarca una amplia gama de ellos. Sin embargo, no le impide agregar funcionalidad extra. Rara vez podría tener que escribir una bindUI o syncUI método si se utiliza el adhesivo proporcionado por MakeNode, pero es posible hacerlo, ya que MakeNode no las utiliza.

Como un bono a aquellos que tuvieron la paciencia de leer hasta aquí, también he modificado el botón Anthony Pipkin conjunto de componentes de la galería:

La documentación de la API se puede encontrar aquí .

Compartir y ampliar: Marcar con del.icio.us | Digg it! | reddit!

6 Comentarios »

RSS feed para los comentarios de esta entrada. TrackBack URI

  1. ¿Es esto compatible con el componente de vista de las nuevas Ryan MVC viene en 3.4.x? ¿Podría ser utilizado para representar el marcado de una manera compatible con ese marco?

    Comentario por Andrew Wooldridge - 09 de julio 2011 #

  2. Andrew ,

    Esta extensión se entiende como una ayuda para construir los componentes, como el botón y ejemplos muestran Spinner, no para construir aplicaciones enteras, como el marco MVC hace. Estos componentes se pueden utilizar en cualquier lugar de cualquier otro componente derivado de Widget puede. En el marco de MVC, sería natural para usar tales componentes en las clases que heredan de Y. Ver para construir la interfaz de usuario, a lo largo de la versión HTML o cualquier otro componente derivado de Widget, si utiliza MakeNode o no.

    Comentario por Satyam - 10 de julio 2011 #

  3. Satyam,

    Esto es muy grande! Yo he experimentado todos los puntos de dolor que usted está tratando con esta extensión Widget. Parece que el uso de esta extensión se puede eliminar una gran cantidad de repetición de la caldera de la placa de código se termina escribiendo la hora de crear widgets personalizados, mientras que la estandarización en la forma de conectarse con el código y la lógica con la DOM y la representación, que es emocionante ver!

    ¿Será usted sumando esto a la YUI 3 Galería, por lo que es más accesible para que la gente. Uso ()?

    Al igual que Andrew señaló que hay cierta coincidencia conceptual con la vista Y. para eventos y la representación, a pesar de la API de ambos son diferentes. Valdría la pena averiguar si existe un terreno común para los dos API a ser más similares (específicamente con la materia de eventos DOM).

    Desde una perspectiva general de la API que usted ha hecho todo lo protegido / privado a través de la '_' (guión bajo) prefijo, tengo curiosidad por conocer su opinión al respecto. Creo que las propiedades estáticas como: `_CLASS_NAMES`, y `_EVENTS, etc puede ser que también acaba de ser:` CLASS_NAMES `, y` `EVENTOS Sans el guión-prefix. Puede que sólo sea mi preferencia, pero que se siente excesivamente protector:)

    Comentario por Eric Ferraiuolo - 12 de julio 2011 #

  4. Eric ,

    Gracias por tu comentario. De hecho, este nació a partir de la repetición aburrida. También me gusta la pulcritud de la componente resultante tanto de él se trata en forma declarativa y la materia procesal se reduce y estandarizados, especialmente todos los métodos _uiSetXxxx.

    No quiero tratar con GitHub y la galería de YUI, así que no lo coloque en ellos. No me importa si alguien lo hace, pero yo no lo voy a hacer o realizar su mantenimiento.

    Lo DOM eventos salió directamente de Y. Vista, excepto que utilizar las teclas de classNames para identificar los elementos, ya que toda la extensión que hace, así, un amplio uso de ellos. También se ocupa de conectar todos los eventos en la jerarquía de clases por lo que no es necesario repetir los al heredar de otras clases.

    En cuanto a los miembros protegidos / privado, he planteado esto con Jenny, que pidió al equipo y he cambiado todos los miembros del público a los anteriormente protegidas en base a ese consejo.

    Básicamente, hay dos funciones de desarrollo, el creador de los componentes y el usuario del componente o 'ejecutor' como Jenny se refirió a ellos. Es mejor si los miembros del grupo significaba para el desarrollador de componentes no el desorden de la documentación de la API para el implementador. En este sentido, muchos miembros de Widget como CONTENT_TEMPLATE, renderUI, HTML_PARSER o Base.ATTRS nunca debió haber sido pública, como el ejecutor ni siquiera debe saber acerca de ellos.

    Por otro lado, los miembros como _uiSetTabIndex o _uiSetDisabled son muy correctamente declaradas como protegidas. Por lo tanto, en el modo de desarrollador de componentes, que siempre debe tener Mostrar protegidas en, mientras que un implementador no lo haga. Esto evitaría que los desarrolladores de componentes de volver a implementar la funcionalidad que ya está allí, al igual que el componente original de los botones en la galería que tenía el código rehacer lo que los dos métodos ya lo hacen.

    Supongo que desde que Jenny tenía que llevar a la selección no había directrices en este sentido y por lo tanto vamos a tener que vivir con una cierta inconsistencia en los componentes existentes.

    Comentario por Satyam - 12 de julio 2011 #

  5. Una actualización:

    He añadido un código de procesamiento más: "1". Es útil en el tratamiento de singular / plural de texto, por ejemplo: {p} {Cantidad 1 {p} Cantidad "unidad" de "unidades"}. Esta cadena se producen ya sea "una unidad" o "unidades de 123", según el valor de Cantidad propiedad.

    Como se muestra en el ejemplo anterior, los marcadores de posición ahora se pueden anidar dentro de otras. Por lo tanto, un argumento para un marcador de posición puede ser el valor devuelto por otro marcador de posición.

    También ha cambiado el marcador de posición para actuar más como el {?}: Operador. En lugar de producir un texto fijo, que permite devolver nada sus argumentos decir, por ejemplo: {? {P} {p Cantidad Cantidad} "none"}.

    Como ejemplo extremo, esta plantilla:

    {? {P} Cantidad "{p} {Cantidad 1 {p} Cantidad" unidad "de" unidades "}", "none"}

    se produce el texto "none", "una unidad", "2 unidades", "3 unidades" y así sucesivamente para valores sucesivos de la Cantidad de propiedad.

    El método de procesamiento de la plantilla está ahora disponible como _substitute método.

    Comentario por Satyam - 13 de agosto 2011 #

  6. Otros cambios:

    Ahora, la propiedad _EVENTS estática, los oyentes de hash definir para cada caso, toma un par de extras selectores virtuales. La estructura de _EVENTS es la siguiente:


    _EVENTS: {
    selector: {
    eventType: listener,
    ....
    }
    }

    donde los seleccionadores son las claves utilizadas en la propiedad _CLASS_NAMES para crear el classNames utilizados en las plantillas para los elementos HTML, lo que facilitar su localización.

    Había dos selectores especiales: '.' indica el boundingBox y '..' el documento de los widgets se in

    Ahora he añadido dos otros selectores virtuales, este, todo en mayúscula, se refiere a sí mismo y el widget Y a la instancia de Y, por ejemplo:


    _EVENTS: {
    THIS: {
    visibleChange: '_afterVisibleChange'
    },
    Y: {
    'broadcastingWidget:somethingChange':'_afterSomethingChange'
    }
    }

    Y la clave, aunque se supone que representan la instancia Y, será tomada por la cadena JavaScript como "Y". Siempre use Y como la clave virtual, incluso si se llama a su instancia YUI algo más, recuerde que es sólo la cadena "Y", no el ejemplo Y real.

    MakeNode sólo se establece después de los detectores de eventos, nunca antes un (a) los oyentes, que es el caso más frecuente. En caso de necesidad de escuchar a un evento de "antes", la levantó como de costumbre.

    Comentario por Satyam - 19 de agosto 2011 #

Deja un comentario

Nota: Los comentarios son moderados, por primera vez. Spam eliminado.

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Organizado por Yahoo!

Copyright © 2006-2011 Yahoo! Inc. Todos los derechos reservados. Política de privacidad - Condiciones del servicio

Desarrollado por WordPress en Yahoo! Web Hosting .