Interfaz de usuario de Yahoo! Blog (YUIBlog)

YUI 3.4.0 Preview Release 3 ya está disponible en CDN

El equipo de YUI acaba de terminar el sprint final de desarrollo para la liberación 3.4.0. En este momento tenemos en cuenta el código funcionalmente completo. Estamos planeando pasar nuestra siguiente sprint se centra en nuestra ronda final de pruebas y la creación de más ejemplos y documentación. Hemos publicado un FC (funcional completa) a construir a la CDN para la exploración de la comunidad y la retroalimentación. Puede acceder a este comunicado en el http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js .

Hay algunas áreas específicas de la biblioteca en la que nos gustaría tener retroalimentación de la comunidad:

• El cargador ha tenido una importante actualización de 3.4.0. Si usted está haciendo las especificaciones del manual de carga a través de use("*") o hacer uso de la configuración submódulo, se lo agradecería mucho que tratar el código con el nuevo cargador para asegurarse de que están correctamente el manejo de todos los casos de uso. Para obtener más información detallada sobre los cambios del cargador en este comunicado, se refieren a la entrada en el blog que describe los cambios Loader 3.4.0 .
• Calendario y Grupo son completamente funcionales y listos para su uso revelador.
• Gráficos:. Ha habido algunos cambios en la API pocos que afectan a cualquier código experimental, escrita en la API de gráficos distribuidos en el comunicado de PR2 getShape() ha cambiado el nombre addShape() . También ha habido varias sustituciones de atributos.
• Transición: transiciones nativos están ahora compatible con Firefox.
• WidgetButtons ha sido lanzado como una extensión de nuevo widget que te permite colocar el CSS de estilo botones en el encabezado y pie de página de cualquier control que implementa el soporte para módulos estándar.
• Plugins Modalidad Widget Widget y ocultación automática-se han convertido en extensiones.
• Widget: Añadido soporte para destruir (true), que se retire y destruya todos los nodos secundarios (no sólo el boundingBox y contentBox) contenidos en boundingBox del Widget. destroy () mantendrá su comportamiento actual, debido a la potencialmente alta en tiempo de ejecución costo de destruir todos los nodos secundarios. Si destruyes Widgets en su aplicación o si es un desarrollador de widgets personalizados, su ayuda en la prueba de este cambio sería apreciada.
• ScrollView ahora admite la paginación vertical, incluye un plugin ScrollView-lista para agregar nombres de las clases CSS para elementos de la lista directas, así como varias correcciones de errores y refactoring
• App Marco: Queremos extender un agradecimiento sincero a todos los desarrolladores de la comunidad que han tomado el tiempo para probar el marco de aplicación nueva. Hemos recibido excelentes comentarios tras la publicación PR2. Por favor, siga estudiando estos componentes y envíanos tus comentarios y sugerencias.

Puede obtener información adicional sobre el contenido de este comunicado mediante la revisión del paquete acumulativo de la historia y la lista completa de los billetes tratados en PR3 . Por favor, envíe sus peticiones de mejora, los errores y retrocesos en la base de datos boleto en YUILibrary.com .

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!

YUI: Horario de jueves 28 de julio

Y.Calendar está llegando a 3.4.0

Calendario es uno de nuestros widgets más populares en el YUI 2 de la familia, y está haciendo su debut en el YUI 3 arquitectura en 3.4.0. Allen Rabinovich es el dueño de los componentes y el autor y será en la llamada que nos reintroducir a este viejo favorito, mostrando algunos nuevos enfoques a los problemas que enfrentan los 2.x Calendario. Estoy particularmente jazzed sobre el apoyo a la internacionalización, pero las nuevas reglas de representación son también bastante fascinante.

Adelante, y trae a tus preguntas selector de fecha, eventos del calendario, la importación-de-iCal-y-hacer-crepes y peticiones con usted como profundizar en la actualidad y el futuro Y.Calendar . (No, no va a importar de iCal, pero si alguien quiere crear un módulo de galería de domar a la bestia, no es seguro que será un boleto YUIConf en él para usted ;))

Estamos de vuelta a nuestra hora habitual de esta semana, por lo que vemos en Conectar a las 10 am PST.

Fecha y detalles

Vamos a estar en línea 10 a.m.-11 a.m. PDT jueves. Los detalles de la conexión son los mismos, como de costumbre.

1. Marque 1-888-371-8922 para (Skype funciona muy bien para no estadounidenses participantes *)
2. Ingrese el código de participante 47188953 #
3. Únete a la sesión de compartir pantalla (esto le preguntará si desea instalar el plugin de Adobe Connect, si esta es tu primera vez con él)

Nota: Debido a que es una línea abierta de conferencias, le pedimos que llamen silenciar sus líneas menos que estén participando en la discusión activa.

* - Si Skype no es una opción, enviarme un email o me coge (ls_n) en el canal de IRC # yui en freenode para un número local.

Grabación

Gracias a todos por llamar a! La grabación de la sesión en línea está ahora disponible.

La alta calidad, el iPhone / iPad compatible con grabación de descarga está aquí .

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!

YUI: Horario jue 21 de julio

Una actualización de DataTable y escaparate de la galería

El ciclo de lanzamiento 3.4.0 está llegando a su fin y se llena de todo tipo de grandes características, pero hablando claramente, DataTable no se ha hecho como foco de desarrollo tanto como debería haberlo hecho. Ha habido algunas correcciones de errores, sin embargo, y una buena cantidad de planificación para los cambios que se vean involucradas en 3.5.0, y un gran comienzo para la participación comunitaria en su desarrollo.

Sabemos que la DataTable es un widget muy importante para una gran cantidad de clientes, por lo que entendemos el costo de retrasar el desarrollo centrado. Este horario de apertura será una actualización de lo que el trabajo está consiguiendo hecho de 3.4.0, lo que está prevista para el 3.5.0, y una introducción a la gran labor que ha empezado a brotar en la Galería de agregar características y corregir los errores de DataTable (y su familia de apoyo a las clases).

Vamos a estar en línea una hora más temprano esta semana para el beneficio de Eamon Brosnan (también conocido como mosén de # Yui), que ha proporcionado una serie de parches Galería vamos a estar mirando por encima. De lo contrario, vamos a tener otros Número de habitantes yui y colaboradores Galería muestran sus mercancías. Si usted tiene una solución DataTable o el trabajo en curso que te gustaría compartir, por favor hágamelo saber para que pueda bloquear la programación para adaptarse a todo (ls_n en el # yui o Twitter ).

Fecha y detalles

Vamos a estar en línea 9 a.m.-10 a.m. PDT jueves. Los detalles de la conexión son los mismos, como de costumbre.

1. Marque 1-888-371-8922 para (Skype funciona muy bien para no estadounidenses participantes *)
2. Ingrese el código de participante 47188953 #
3. Únete a la sesión de compartir pantalla (esto le preguntará si desea instalar el plugin de Adobe Connect, si esta es tu primera vez con él)

Nota: Debido a que es una línea abierta de conferencias, le pedimos que llamen silenciar sus líneas menos que estén participando en la discusión activa.

* - Si Skype no es una opción, enviarme un email o me coge (ls_n) en el canal de IRC # yui en freenode para un número local.

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!

Next-Gen YSlow powered by YUI

Un par de semanas, Yahoo! anunció YSlow para móviles en la velocidad de 2011 , con lo que el poder de análisis de rendimiento YSlow para el mundo móvil.

YSlow para móviles funciona como un marcador , por lo que es posible ejecutar en otros navegadores de Firefox (como un add-on) o Chrome (como una extensión) .

La arquitectura YSlow fue rediseñado parcialmente al trabajo multiplataforma y YUI fue el factor esencial para hacer caja de arena, multi-navegador y acceso a la abstracción simple posible YQL.

Sandboxing

Con el fin de ser embebido en una página sin interferir con el análisis de rendimiento y sin jugar con la propia página, YSlow es un bookmarklet que inyecta JavaScript y CSS en cualquier página mediante el aprovechamiento de la potencia de YUI sandboxing:

Bookmarklet URL:

 javascript: (function (Y, P, O) {
     p = y.body.appendChild (y.createElement ('iframe'));
     p.id = 'YSlow-marcador ";
     'display: none' p.style.cssText =;
     o = p.contentWindow.document;
     o.open (). write ('
         <head>
         <Body onLoad = "
             YUI_config = {
                 victoria: window.parent,
                 doc: window.parent.document
             };
             var d = documento;
             d.getElementsByTagName (\ 'cabeza \') [0]
                 . AppendChild (
                     d.createElement (\ "script \")
                 ). Src = \ 'http://d.yimg.com/jc/yslow-bookmarklet.js \' "
         >
     ');
     o.close ()
 } (Documento))

El código anterior:

• crea un vacío iframe;
• anexa al cuerpo de la página;
• * oculta el iframe;
• obtiene su manejador de ventanas;
• escribe en su contenido el cuerpo del iframe;
• este cuerpo está vacío, pero tiene un onload de eventos
• el onload de eventos define cómo inyectar YSlow JS:
  • establece YUI_config , por lo que win y el doc puntos a la página que se analiza window y el document , respectivamente,
  • dinámicamente inyecta URL YSlow mediante la creación de un script elemento en iframe head

* El iframe se muestra en el momento de presentación de todos los activos se cargan YSlow

Esto pondrá un iframe en la página que se analiza. Este iframe actuará como un entorno de espacio aislado y YSlow residirá dentro de ella. Desde el iframe se crea dinámicamente sin la src atributo, tendrá acceso a su casa matriz (la página se está analizando), porque no hay origen, la misma política violación sucediendo allí.

El YUI_config objeto es muy útil ya que establece win y doc al padre del iframe (la página se está analizando), por lo que cualquier nueva instancia de YUI será atado en el documento principal de forma predeterminada, el cableado de cualquier llamada a Y.all y Y.one través de Y.config.win o Y.config.doc de la YUI use de devolución de llamada.

La presentación de YSlow es manejado por el iframe window y el document hace referencia, lo que permite el script principal YSlow para hacer que el margen de beneficio, así como buscar la CSS externa dentro de este iframe sin entrar en conflicto con los estilos de la página de los padres. YSlow analiza la página principal con el fin de obtener todos los componentes (imágenes, scripts, enlaces, imágenes de fondo, flash, etc) necesarias para el análisis del rendimiento posterior. Esto se hace mediante el acceso a Y.config.win y Y.config.doc , ya que se refieren a la página principal.

Cross-browser abstracción

Ser un bookmarklet, YSlow para móviles se supone que funciona en cualquier navegador *. YUI abstrae cross-browser problemas por la normalización de las diferencias entre navegadores, lo que resulta en un lugar limpio, fácil de leer y fácil de mantener código base.

YSlow no ha sido portado plenamente a YUI 3 - sólo la capa de control (desde el componente de aplicación próxima) por ahora - pero aún así, todo tipo de manipulación DOM y la gestión de eventos son realizados por los node y el event los módulos. En futuras versiones se planea migrar más características YSlow para YUI 3.

* No todos los navegadores son compatibles actualmente

YQL

YSlow analiza las páginas mediante la comprobación de las cabeceras HTTP de los componentes que se encuentran en la página. Cabeceras HTTP de respuesta no están disponibles en la página, por lo tanto, los componentes deben ser solicitados de nuevo para obtener la información de YSlow cabecera de la respuesta. Esto podría lograrse mediante la solicitud de la lista de URLs componente a través de XMLHttpRequest (AJAX), pero desafortunadamente debido a las mismas restricciones que la política de origen , esto no es posible a menos que todos los componentes están en el mismo dominio que la página que es muy poco probable.

Una solución común para la misma restricción normativa de origen está utilizando JSONP, donde un servidor externo funciona como un proxy que solicita la lista de direcciones URL de los componentes y la recuperación de sus cabeceras de respuesta HTTP en nombre de YSlow. Debido a la popularidad YSlow y los recientes esfuerzos móviles de análisis de rendimiento, estamos esperando el tráfico muy pesado para el YSlow para el bookmarklet móvil. A fin de apoyar este tipo de tráfico, YQL fue la solución adoptada por YSlow escalable a través de una tabla de datos abierto llamado data.headers , que recupera los encabezados de respuesta y el contenido de una determinada lista de direcciones URL, mientras que pasar por el agente de usuario para garantizar el contenido que se espera es recuperado.

La consulta YQL componente hace todo el trabajo de la gestión de las consultas, mientras que la gestión de las solicitudes YQL JSONP bajo el capó, por lo que el código del controlador YSlow mucho más simple y fácil de mantener.

Futuras mejoras: YSlow Nueva interfaz amigable para el móvil

Actualmente, el YSlow de la experiencia del usuario móvil es la misma que la experiencia de escritorio. Lidiar con una larga lista de datos de análisis de rendimiento no es la mejor experiencia en las pequeñas pantallas de teléfonos inteligentes. Desde YUI también abstrae de dispositivos cruzada gestos , YSlow para móviles tendrá un nuevo móvil de fácil manejo en futuras versiones.

Rendimiento de la herramienta de rendimiento

YSlow para el despliegue móvil se hizo con cuidado teniendo en cuenta su impacto en el rendimiento en el tiempo de carga de la página que se analiza. Los YUI 3 módulos utilizados en YSlow se analizaron para incluir sólo los módulos necesarios para cargar YSlow lo más rápido posible. El archivo de las semillas de YUI y cargador no se incluyeron ya que todos los módulos necesarios y submódulos se combinaron después de rendimiento Zen Ryan Grove consejos, lo que hizo posible cargar todo junto en una sola pequeña petición individual: YSlow-bookmarklet.js: 204KB, 66KB ( gzip) donde:

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

Más información sobre YSlow

Manténgase al día con los últimos anuncios de YSlow por:

• Visitar la página de YSlow rediseñado getyslow.com
• YSlow gusto en Facebook: facebook.com / getyslow
• Después de YSlow en Twitter: twitter.com / getyslow

Sobre el autor: Marcel Durán es el principal Front End para el equipo de Yahoo! 's de rendimiento excepcional. Ha sido en la optimización del rendimiento de Web en los sitios de alto tráfico en la página principal de Yahoo! frontal y equipos de búsqueda en la que se aplican e investigado las prácticas de las mejores web de rendimiento que hacen las páginas más rápido. Él ahora se dedica a YSlow y el desarrollo de otras herramientas de rendimiento, las investigaciones y la evangelización. Su objetivo es hacer de la web, incluso más rápido de lo que puede ser y cree que no hay tal cosa como "sólo unos pocos milisegundos no le hará daño".

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!

Navegador de actualización gradual de Apoyo

Los cambios de EGB

Los cambios específicos de esta actualización son:

• Ya no se asignan los grados de experiencia
• Descatalogado prescribir sistemas operativos específicos (a excepción de móvil)
• Cobertura adicional para Internet Explorer 9
• Alta cobertura de Firefox 4. †
• Alta cobertura de Firefox 5. †

Notas:

• El símbolo de daga (como en "Firefox 4. †") indica que la mayoría de la corriente no la versión beta en ese nivel de la sucursal recibe el apoyo.
• No se da orientación sobre iOS o Android el uso de dispositivos del sistema operativo. La recomendación es que elija los dispositivos que sean más representativos de su base de usuarios de cada sistema operativo.

Extracción de Grados de la Línea de Base prueba del navegador

Esta edición de la actualización de EGB representa una desviación de nuestras actualizaciones anteriores en que nos estamos alejando de los navegadores de mapas directamente a los grados de experiencia (por ejemplo, "A-grado" y "C de grado"). En lugar de prescribir lo que la experiencia del usuario es apropiado para que los navegadores, nos centraremos en la definición de una estrategia de línea de base de prueba eficiente que maximiza la cobertura de la prueba y reduce al mínimo la superficie de la prueba. Por ejemplo, todavía importantes a nivel mundial garantiza cuota de mercado de IE6 continuaron las pruebas; EGB Sin embargo hoy en día permite que la experiencia del usuario de IE6 a ser diferente de la experiencia de IE9.

Extracción de los sistemas operativos de la Línea de Base prueba del navegador

Con el fin de optimizar las pruebas y reducir al mínimo las necesidades de recursos, ya no especificar qué sistema operativo debe ponerse a prueba. La única excepción es cuando el navegador está estrechamente unida a la versión del sistema operativo, en cuyo caso nos referimos a la versión del sistema operativo en lugar de la versión del navegador (por ejemplo, "Safari de iOS 4"). Esto nos permite centrarnos cobertura de la prueba en las versiones del navegador, y minimizar los ensayos redudant a través de plataformas. Problemas con el mismo navegador en las versiones son insignificantes, y en general en relación con las diferencias de nivel superior del sistema operativo, tales como el manejo de claves y fuentes disponibles. El código que se sabe que afectan a cuestiones de plataforma cruzada debe ser probado en tantas plataformas como sea posible, pero por lo general esta prueba se puede aislar a los temas específicos en lugar de ejecutar una prueba de regresión completa de todas las funciones. Se recomienda alinear el sistema operativo prioritario las pruebas con su base de usuarios.

¿Por qué es IE6 todavía en la lista?

IE6 todavía tiene una importante cuota de mercado global lo suficiente como para justificar una experiencia contrastada de uso aceptable. Un error común con la estrategia de mejora progresiva ha sido que una vez que entra en un navegador "grado C" que se convierte en "no admitido", cuando en realidad lo que realmente significa que se debe entregar la experiencia de sólo HTML. Ahora que ya no prescriben que los navegadores recibir lo que la experiencia, esto se deja para los proyectos para decidir sobre la base de sus usuarios y recursos. El SGB se centra en la especificación de que los navegadores necesitan una experiencia contrastada útil sobre la base de factores tales como la cuota de mercado e influencia. Definir lo que es "utilizable" y especificando los niveles aceptables de degradación se dejan para que los equipos decidan. Todavía promover una sencilla mejora progresiva del modelo, y desalentar los proyectos de la creación de nuevos niveles sin tener en cuenta los costos adicionales en el desarrollo, pruebas y recursos de mantenimiento.

Pronóstico de EGB

Esperamos hacer los siguientes cambios en la próxima actualización:

• Deje de cobertura para Safari en iOS 3.
• Agregar la cobertura de Webkit en Android 3.
• Agregar la cobertura de Firefox 6.
• Agregar la cobertura de Safari de iOS 5.

El Archivo de EGB

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

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!

El "MakeNode" Widget de Extensión

Nota del editor: Desde que este artículo fue publicado originalmente, el módulo de MakeNode se ha publicado en la galería de YUI y recibió algunas mejoras. Por favor, consulte el artículo de actualización, Actualización: El "MakeNode" Extensión Widget .

En mi artículo anterior, 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 le quitó la 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. Por otro lado, que está estrechamente integrado con el YUI Widget clase de fundación, incluyendo ayudantes de nombre de clase y de 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 giratorio modificado ( JS , CSS , sprites ), así como un ejemplo están disponibles a partir de mi sitio. Los enlaces a recursos adicionales se pueden encontrar al final de este artículo.

Ampliación de su componente

Una vez que se carga MakeNode, es necesario incluir el módulo en su YUI().use() comunicado con el nombre de 'makenode' . Luego, para ampliar su widget, en la siguiente lista en el tercer argumento de Y.Base.create() , de esta manera:

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

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

Todos los miembros de esta extensión son bien protegido o privado, ya que están destinados a ser utilizados por el desarrollador de componentes y no por el implementador utilizando esos componentes, que no debe ser molestado con ellos.

La definición de la plantilla

La primera cosa que normalmente se 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}"> botón </>',
     '<button Type="button" title="{s down}" class="{c down}"> botón </>'
 ]. Join ('\ n'), 

La plantilla por defecto por lo general será nombrado _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 la versión HTML y una serie de marcadores de posición encerrados en llaves, cada una compuesta 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} configuración de valor del atributo

• {p propertyName} valor de instancia de la propiedad

• {m methodName arg1 arg2 ….} valor de retorno del método dado. El código de procesamiento es seguido por el nombre del método y de cualquier número de argumentos separados por espacios en blanco. Las cadenas deben ir entre comillas dobles. Números, booleanos y null serán convertidos de la cadena en sus tipos de datos propios

• {c classNameKey} CSS className generada a partir del _CLASS_NAMES propiedad estática

• {s key} de la cadena de strings atributo, utilizando key como el atributo sub-.

• {? other placeholder } Produce la cadena de checked si el resultado de procesar el resto del marcador de posición es verdadera.

• {} 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, todas separadas por espacios en blanco, que se pasan al método dado. Estos argumentos pueden ser números, null , true , false o cadenas entre comillas dobles. MakeNode magia, los analizará y los convierte a sus propios tipos, 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”) para que los dos primeros argumentos se convierten en sus tipos de datos correctos y la cadena puede contener espacios. Para incluir una comilla doble, utilice \\" , la doble barra invertida que se requiera debido a que JavaScript va a interpretar una sola y descarta que antes de llegar a MakeNode. Sólo se permiten comillas dobles, MakeNode no utiliza eval() por lo que el analizador se limita Cualquier cosa, pero seguro. pero los números, null , booleanos y cadenas entre comillas dobles será ignorado.

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

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

Otros marcadores de posición se puede añadir a MakeNode mediante la adición de ellos en la _templateHandlers hash.

El _CLASS_NAMES la propiedad

Junto con el ATTRS y _TEMPLATE atributos estáticos, podemos definir una _CLASS_NAMES la propiedad que apunta a una matriz de cadenas. Cada una de esas cadenas se utiliza para generar una className. Así _CLASS_NAMES: ['input'] se producen el className “yui3-spinner-input” . Esos nombres de las clases 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 la propiedad de generar cualquier cantidad de nombres de las clases, ya sea que los use en la plantilla o no. Usted todavía puede llegar a los nombres de las clases 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 convirtió 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á los nombres de las clases para el boundingBox y el contentBox , el primero bajo el "." clave y el segundo bajo el “content” fundamental. Widget asigna a la boundingBox los nombres de las clases derivadas 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 className de más arriba para el boundingBox .

Si un componente es de varios niveles de distancia de Widget, como SuperSpecialSpinner heredera de SuperSpinner que hereda de Spinner que hereda de Widget, y si alguno o todos de ellos tienen _CLASS_NAMES propiedades definidas, MakeNode producirá nombres de las clases 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 los nombres de las clases producidas en cada nivel se utilizará el valor de la NAME propiedad de ese nivel. Así, en SuperSpecialSpinner , {c input} aún resultará en “yui3-spinner-input” y no “yui3-superspecialspinner-input” y por lo tanto mantendrá su archivo CSS sigue siendo válida.

El marcador de posición {s}

Widget tiene una strings atributo de configuración definida, aunque no se inicializa con un valor cualquiera. Este atributo tiene la intención de mantener las cadenas que son visibles (o, a través de lectores de pantalla, leer) el usuario. Es importante que nunca se incluyen 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 se van a ver o leer por el usuario siempre debe ser colocado en la strings atributo. La strings atributo contiene un valor hash donde se ubica cada texto individual por su clave. El componente de Spinner tiene las siguientes cadenas de texto, que se puede ver que se usan en la plantilla anterior.

  cuerdas: {
     valor: {
         de entrada: "Pulse la flecha arriba / abajo para incrementos menores, en la página arriba / abajo para mayores incrementos."
         así: "Incremento",
         abajo: "Disminuir"
     }
 }, 

La mejor parte de hacer 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')}); 

Configuración de los atributos de configuración de strings de esta manera reemplaza la configuración predeterminada de strings valores con los del archivo de recursos de idiomas utilizando el lenguaje se ha definido previamente. La {s} marcador de posición tiene acceso a las cadenas almacenadas en la strings atributo, ya sea la falta de pago o los más traducidos, si está configurado. La {s xxxx} marcador de posición es, de hecho, nada más que un acceso directo a la {@ strings.xxxx} marcador de posición. Sin embargo, la primera sólo se puede acceder a cadenas en el nivel superior, mientras que, por ejemplo, {@ strings.xxxx.yyyy.zzzz} le permitiría acceder a una cadena de más abajo.

Usando _makeNode en renderUI

Usamos la plantilla para crear el marcado en el componente. Para ello, podemos llamar a MakeNode de _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 de la transformación de la plantilla. El _makeNode método devuelve una instancia de Y.Node que pueda ser añadido o insertado en cualquier lugar o que acaba de celebrarse para su uso posterior. No devolver una cadena, se produce un Node la instancia.

El _makeNode método toma dos argumentos opcionales: una referencia a una plantilla y un objeto para rellenar los marcadores de posición, como Y.substitute hace. En nuestro ejemplo Spinner simple no es 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 para la parte principal y lo llaman de nuevo con diferentes plantillas para rellenar las partes adicionales. El ejemplo contiene esta renderUI método:

  renderUI: function () {
     var fieldset = this._makeNode ();
     this.each (function (elemento) {
         fieldset.appendChild (this._makeNode (MultipleTemplates.RADIO_TEMPLATE, elemento));
     }, Este);
     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 se llenará con los valores tomados de los elementos almacenados en la lista de arreglo y los nodos resultantes anexos a la 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 en el objeto principal. Los elementos anidados se procesan como Y.substitute haría.

El método _locateNodes

MakeNode proporciona además un _locateNodes método que tratará de localizar todos los elementos con los nombres de las clases declaradas en _CLASS_NAMES . Para localizar los elementos específicos que puede pasar cualquier número de teclas className, de lo contrario, _locateNodes trata de todos ellos. Para cada elemento que se encuentra de cada className, _locateNodes producirá una propiedad de instancia privada que utiliza el prefijo de subrayado seguido por el nombre de la 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 estática _EVENTS

Una de las propiedades más se puede definir a lo largo de las líneas de _TEMPLATE y _CLASS_NAMES y que es _EVENTS . _EVENTS contendrá un hash formado por teclas con nombre de la clase, cada uno con un valor hash de los tipos de eventos y los métodos para manejarlas. 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 is an object (a hash) with any number of properties. The names of the properties, that is, the keys of the hash, identify the elements whose events we will listen to. They are the same identifiers used in _CLASS_NAMES . There are two extra special keys "." and ".." . While the className keys refer to elements nested within the contentBox , the "." key refers to the boundingBox itself while ".." refers to the document containing this widget. Think of them as doing a chdir command when located at the boundingBox level. The _EVENTS property is processed after the renderUI , bindUI and syncUI methods have been called so the widget is expected to be already inserted within the document body, otherwise the ".." will fail.

Each of the entries in _EVENTS is a further object that uses the type of event as its key and the name of an instance method to handle it. _EVENTS , being a static variable, has no access to this so it cannot take actual function references, only the name of the event listener method. Some event types need extra arguments, such as the key event. In that case, instead of providing the name of the event handler you can provide an object with properties fn and args to hold the function name and the extra arguments, when required.

MakeNode will use Node.delegate to listen to the events of the nested elements, while it will use Y.on to listen to events from the boundingBox and the document body. (Note: listening to the key event on any nested element works only with version 3.4.0pr1 and above, since delegation of the key event was not available before. All the other features work with previous versions as well.)

The _EVENTS declarations are cumulative when components inherit from one another. Each class in the inheritance chain will have its own _EVENTS declaration processed separately.

The _ATTRS_2_UI static property

Events go both ways, from the UI to the component and from the component to the UI. The first are handled by the _EVENTS property. Then there are the events fired by attribute value changes that need to be reflected in the user interface. As I mentioned in the previous article, when there are any secondary effects from changing a configuration attribute, they should be handled by change event listeners, not by the optional setter method of the attribute, which should only deal with normalizing the value being set. The UI should reflect the state of the configuration attributes, first in syncUI , when being initialized and then on every attribute change event. For the latter, we need to attach an event listener, which we do in bindUI . Widget already provides a mechanism to make that simple, which I described in the comments to the previous article.

Widget uses the instance property _UI_ATTRS that contains an object with two further properties, SYNC and BIND . Each of these is an array listing the names of the configuration attributes to be initially synched and then listened to in order to keep the UI reflecting current values. Widget expects each of those entries to have a method associated with it, named after the attribute name prefixed by _uiSet with the first character of the attribute name converted to uppercase to have the method name in proper camel case. Thus, if "value" was listed in any of the _UI_ATTRS arrays (in either SYNC or BIND ), Widget would expect to find a _uiSetValue method. This method will receive two arguments, the value being set and the src of the change. This is the code for our Spinner _uiSetValue method:

 _uiSetValue : function(value, src) {
    if (src === UI) {
        return;
     }
    this._inputNode.set(VALUE, this.get(FORMATTER)(value));
}, 

All the uppercase identifiers you see in this piece of code correspond to string constants declared elsewhere, to allow the YUI compressor to do its job better. The method, basically, sets the value HTML attribute in the <input> box to the new value set, after being formatted. The reference to the textbox was provided by _locateNodes . The src argument is initially checked to see if set to the string value 'ui' . If this is so, no action will be taken. This is to avoid endless loops. If the user enters something in the input box, its value would go into the value configuration attribute which then would fire a valueChange event, which would get _uiSetValue called which, if unchecked, would then go and change the value of the input box, which would trigger the whole process again. Thus, in _uiSetValue , if we know the change comes from the UI, we do nothing and so break the loop. However, this requires another piece of code elsewhere. In the listener for the DOM event, when we set the configuration attribute, we use the third optional argument to set, like this:

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

It is up to us to ensure that changes coming from the UI are flagged thus and then check that same flag to avoid loops.

With all this said, I haven't yet mentioned the static property _ATTRS_2_UI mentioned in the heading of this section. As the comments in my previous article shows (through the blunders I made in them), making sure that all attributes affecting the UI are properly listed is somewhat messy. You should never initialize _UI_ATTRS from scratch since Widget already lists a whole lot of attributes and those would be lost. You have to concatenate new attribute names over the existing ones, which is somewhat hard to remember how to do it right. To make it simple, MakeNode will read from the static property _ATTRS_2_UI and do that concatenation for you. It will concatenate all such lists from each and every class in the inheritance chain so at each level each class can handle its own attributes. In Spinner, we have:

 _ATTRS_2_UI: {
    BIND: VALUE,
    SYNC: VALUE
}, 

MakeNode will accept both an array of names or a single attribute name, as in this case.

The question naturally arises, why two lists, one for binding the other for syncing? Quite often the SYNC array has fewer entries than the BIND list and this is because the template for the component might already have the very same default value as the configuration attribute and there is no need to do an initial syncing. 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
• example

The API docs can be found here .

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

YUI and Loader changes for 3.4.0

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. Por ejemplo:

    "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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!