Interfaz de usuario de Yahoo! Blog (YUIBlog)

Límites móviles caché del navegador: Android, iOS y webOS

28 de junio 2010 a las 8:45 am por Ryan Grove | En Desarrollo y Performance | 19 comentarios

Actualización (12 de julio de 2010): Si bien los resultados descritos en este artículo son precisas para las páginas HTML, nuevas pruebas han puesto de manifiesto los límites de la caché muy diferentes para los recursos CSS y JS. Los resultados actualizados se describen en los límites de Mobile Browser Cache, Revisited .

A principios de 2008, Wayne Shea y Theurer Tenni escribió una entrada de blog de ​​YUI en almacenamiento en caché de iPhone en el que compartió los resultados de la investigación de diversas características y limitaciones de la memoria caché de Mobile Safari en el iPhone OS 1.x Entre otras cosas, encontraron que los componentes individuales más grandes que no eran 25KB caché, y que no había un tamaño máximo de caché total de entre 475KB y 500KB.

Mucho ha cambiado desde entonces. Hemos visto dos nuevos lanzamientos importantes y muchas versiones menores del iPhone OS (ahora IOS), y varios otros dispositivos móviles con navegadores de alta capacidad han surgido para desafiar al iPhone. Stoyan Stefanov encontrado, a finales de 2009, que los límites de la caché del iPhone ha cambiado (por desgracia, para mal). Pero, ¿dónde están las cosas ahora? Y ¿qué pasa con los navegadores no-IOS?

Fondo

Los navegadores tienen dos tipos de cachés que estamos preocupados por los efectos de estas pruebas:

• El caché del componente, o caché de objetos, almacena los archivos individuales. HTML, CSS, JavaScript, y todas las imágenes entra en la caché del componente. Cada vez que necesita uno de estos componentes, el navegador comprueba primero la caché antes de hacer una solicitud de red.
• La caché de la página, también conocida como la caché adelante / atrás, almacena una página entera y todos sus componentes, así como su estado actual. Cuando se utiliza la parte de atrás hacia adelante o el botón, el navegador carga la página de la caché de la página si es posible.

El caché de la aplicación HTML5 es otro tipo de caché que es ampliamente soportado por los navegadores móviles. Los fabricantes de navegadores ya lo hacen un buen trabajo de documentación de los límites de la caché de la aplicación, por lo que no se incluyen en mis pruebas. Más información sobre el caché de la aplicación más tarde.

Dispositivos de Prueba

He probado los siguientes móviles navegador / plataforma de combinaciones:

• Android 2.1 (Nexus One)
• Mobile Safari en iOS 3.1.3 (primera generación de iPhone)
• Mobile Safari en iOS 3.2 (iPad)
• Mobile Safari en iOS 4.0 (iPhone 3G)
• Mobile Safari en iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Nota: Con la excepción de Mobile Safari en iOS 4.0, he probado un solo dispositivo en cada categoría. Si existen diferencias entre los dispositivos individuales o las diferencias basadas en el software instalado más allá del sistema operativo, mis pruebas no detectan estas variaciones. Estos dispositivos particulares se pusieron a prueba, porque ellos son los que tuve acceso a no, porque considero que es más importante que otros dispositivos.

Metodología

Pruebas de memoria caché es tedioso, pero relativamente simple.

Escribí una pequeña aplicación Sinatra ( tenedor que en GitHub! ) que genera una respuesta que consiste en un número determinado de caracteres alfanuméricos y los bytes pseudoaleatorios espacios en blanco. Las respuestas pueden ser servidos con gzip o sin comprimir. Los siguientes extrema futuras cabeceras de respuesta de caducidad se envían para asegurar que todas las respuestas se consideran cacheable:

 Cache-Control: max-age = 315360000
 Expira: Vie, 01 de mayo 2020 03:47:24 GMT

Por encima de mi red local, entonces manualmente realiza los siguientes pasos en cada dispositivo para poner a prueba la memoria caché de los componentes:

1. Carga de la prueba de memoria caché de la página de índice.
2. Toque en un enlace a un componente de un determinado tamaño, que van desde 5 KB a 20 MB, y esperar a que termine de cargarse.
3. Pulse el botón Atrás.
4. Pulse en el enlace mismo. Observar si los caracteres al azar son los mismos, y si la consola del servidor imprime una entrada de registro para una petición, para determinar si el componente se almacenó en caché en el paso 2.
5. Repetir y ajustar el tamaño de los componentes según sea necesario para determinar el tamaño máximo que los componentes se almacenan en caché.

Para poner a prueba la memoria caché de la página, me llevaron a cabo esencialmente los mismos pasos, excepto que en lugar de pulsar el enlace de nuevo en el paso 4, hice tapping botón de avance del navegador, haciendo que se utiliza la caché de páginas en lugar de la memoria caché de los componentes.

Apoyo a la ETag y Last-Modified se determinó ajustar el servidor para enviar el caso ETag o Last-Modified cabeceras de respuesta (en las pruebas por separado) y omitir las cabeceras de vencimiento de largo en el futuro. Luego inspeccionó las cabeceras de petición recibidos por el servidor para comprobar que el navegador envía la espera If-None-Match o If-Modified-Since encabezados en el paso 4.

Resultados

He probado tanto con gzip activado y desactivado, pero me di cuenta de que gzip no tuvo efecto en almacenamiento en caché en cualquier dispositivo. El tamaño de los componentes sin comprimir es lo que importa en todos los casos, independientemente de si o no ese componente se sirve gzip. Como tal, todos los tamaños de los componentes mencionados aquí son los tamaños sin comprimir.

La siguiente tabla ilustra mis conclusiones generales.

Tabla: características móviles de memoria caché del navegador

Browser / OS / Dispositivo	Límite de un solo componente	Límite total de componentes	Caché de página Límite de tamaño	Soporta Last-Modified	Soporta ETag	Sobrevive Ciclo de encendido
Android 2.1 (Nexus One)	~ 2 MB (~ 2.048.000 b)	~ 2 MB (~ 2.048.000 b)	∞ 2	Sí	Sí	Sí
Safari Mobile, iOS 3.1.3 (primera generación de iPhone)	0b 1	0b 1	∞ 2	No	No	No
Safari Mobile, iOS 3.2 (iPad)	25.6KB (26214 b)	~ 281.6KB (~ 288.354 b)	25.6KB (26214 b)	Sí	Sí	No
Safari Mobile, iOS 4.0 (iPhone 3G)	51.199KB (52428 b)	~ 1.05MB (~ 1.100.988 b)	∞ 2	Sí	Sí	No
Safari Mobile, iOS 4.0 (iPhone 4)	102.399KB (104 857 b)	~ 1.9MB (~ 1.992.283 b)	∞ 2	Sí	Sí	No
webOS 1.4.1 (Palm Pre Plus) 3	~ 1 MB (~ 1.048.576)	?	~ 1 MB (~ 1.048.576)	No	No	Sí

Androide

El navegador de Android mostró el mejor comportamiento de caché de todos los dispositivos probados. Aunque parece que no limitan el tamaño de los componentes individuales, el tamaño total de caché parece estar limitada a aproximadamente 2 MB, lo que significa que los componentes individuales se limitan efectivamente a 2MB también.

El caché de la página que parecía no imponer ningún límite en el tamaño de las páginas individuales, felizmente el almacenamiento en caché cada byte que arrojó a ella hasta que la memoria RAM disponible se agotó y se estrelló contra el navegador.

Me sorprendió gratamente encontrar que la caché de Android componente sobrevivido tanto reinicia tu navegador y los ciclos de energía, un no logro de los dispositivos IOS fue capaz de igualar.

Posible advertencia: Una revisión de árbol de la fuente de Android WebKit me lleva a creer que sus límites de caché puede adaptar sobre la base de la cantidad de memoria RAM y / o memoria flash disponible en el dispositivo en particular en el que se está ejecutando. Si es cierto, estas cifras sólo pueden ser aplicables a la Nexus. De hecho, si el tamaño de la caché se adapta sobre la base de la memoria no utilizada en lugar de la memoria total, estas cifras sólo pueden ser aplicables a mi Nexus One.

Puedo estar equivocado, pero las diferencias en los resultados de la prueba iOS 4.0 en el iPhone 3G y el iPhone 4 apoyan esta teoría. (Android y Safari Mobile son navegadores basados ​​en WebKit, por lo que puede tener este comportamiento en común.) Si usted está familiarizado con la fuente de WebKit y puede arrojar más luz sobre esto, por favor ponerse en contacto conmigo.

iOS

Los resultados variaron enormemente en las tres versiones más recientes de IOS. Sorprendentemente, Mobile Safari en iOS 3.1.3 no almacenar en caché los componentes de cualquier tamaño, a pesar de tener un tamaño de página de memoria caché de apariencia ilimitada. Esto es preocupante ya que significa que los usuarios de iOS 3.1.3 es probable conseguir una experiencia de navegación óptima, sobre todo si no están usando wifi. El tamaño de la página de caché ilimitada poco sirve aquí, ya que sólo entra en juego para atrás / adelante navegaciones. Este comportamiento es un cambio significativo de lo que otros observaron en las versiones anteriores de iOS y no puedo imaginar una buena razón para ello, así que sospecho que esto puede ser un error.

Mobile Safari en iOS 3.2 (que sólo está disponible en el iPad) no presenta este error. Su límite de componentes 25.6KB y ~ 281.6KB límite de la caché total es mejor que nada, pero aún así parece insignificante en comparación con los demás sistemas. Únicamente entre los dispositivos IOS, el iPad parece limitar el tamaño de las páginas en el caché de la página de 25.6KB, al igual que su límite de tamaño de los componentes.

Mobile Safari en iOS 4.0 exhiben diferentes límites de los iPhone 3G y el iPhone 4, lo que implica que los límites adaptan sobre la base de la memoria RAM disponible (el iPhone 3G tiene 256 MB, mientras que el iPhone 4 tiene 512 MB, ambos dispositivos probados tenía 32 GB de memoria flash) . En el iPhone 3G, el iOS 4.0 tiene un límite de tamaño de los componentes 51.199KB y una ~ 1.05MB tamaño total de caché de componentes.

En el iPhone 4, el límite de tamaño de los componentes era casi exactamente dos veces el límite en el iPhone 3GS, en 102.399KB. El tamaño de los componentes de caché total fue de aproximadamente 1,9 MB. Tal vez debido a iOS 3.2 y iOS 4.0 se han desarrollado por separado, pero ramificado a partir de un ancestro común, el iOS 4.0 tamaño de caché de la página parece estar limitado sólo por memoria RAM disponible en ambos dispositivos probados, al igual que iOS 3.1.3.

Ninguno de los dispositivos IOS conserva el contenido de la caché del navegador en todos los reinicios forzados o los ciclos de alimentación de los dispositivos, aunque sí preservar la memoria caché cuando el conmutador de aplicaciones sin tener que matar el navegador.

webOS

Mis resultados de las pruebas de webOS son tan inconsistentes que tengo poca confianza en ellos. He incluido los pocos datos que logró reunir exclusivamente para el bien de la integridad. Por favor, llévelo con un grano de sal fuerte.

Lo más cerca que yo era capaz de determinar, webOS podría tener un límite de tamaño de los componentes individuales de alrededor de 1 MB, con un límite de tamaño de página en la caché de la página. No he podido convencer a If-None-Match o If-Modified-Since encabezados de la solicitud de webOS, lo que implica que no es compatible con ETag y Last-Modified .

En algunas pruebas, parece que el tamaño del webOS de componentes de máxima fue mayor de 1 MB, pero esto era incompatible. Por lo que yo puedo decir, webOS parece tener un desagradable error que, después de un cierto punto, posiblemente, cuando el tamaño total de caché máximo se alcanza-la memoria caché sólo se detiene por completo de funcionar por completo hasta que el teléfono es el poder de volver a arrancar. En algunos casos, incluso ciclos de encendido no se soluciona la rotura de caché, así que finalmente renunció a tratar de establecer la causa exacta del problema y los límites exactos de la caché de webOS.

Recomendaciones

En base a estos resultados, ofrecemos las siguientes recomendaciones a cualquier persona el desarrollo de aplicaciones web para los dispositivos probados:

• El uso de largo en el futuro las cabeceras de caducidad de la caché. Esto evitará que el navegador de tener que enviar una petición GET condicional, y mejorará el almacenamiento en caché en webOS, que no es compatible con ETag o Last-Modified .
• Por lo menos hasta iOS 4.0 llega en el IPAD, trate de limitar el tamaño de los componentes individuales de 25.6KB o menos, sin comprimir. E instar a los usuarios de iPhone para actualizar a iOS 4.0 tan pronto como sea posible.
• Si su sitio web debe ser compatible con iOS 3.1.3 los usuarios (lo cual es probable), si se requiere de los componentes más grandes que 25.6KB, o si el tamaño total de todos sus componentes es mayor que 281.6KB, considere el uso de la caché de aplicación HTML5, localStorage , o de almacenamiento de base de datos para almacenar sus componentes. Alex Kessinger reciente de YUI entrada del blog, Introducción al uso de YUI 3 en aplicaciones fuera de línea , podría ser de interés para los desarrolladores de YUI 3 teniendo en cuenta este enfoque.
• Haga su propia prueba. No asuma que estos resultados se aplican a cualquier versión futura de cualquiera de los navegadores o dispositivos probados. Utilizar estos resultados como punto de partida, pero verifique usted mismo antes de tomar decisiones importantes basadas en suposiciones acerca de las limitaciones de memoria caché móviles. Los cambios del navegador móvil del mundo a un ritmo relámpago, por lo que esta investigación tendrá una vida útil muy corta.

He hecho mi código de prueba está disponible en GitHub y os animo a usarlo, tenedor, y compartir lo que aprende.

Convocatoria de Documentación

Los fabricantes de navegadores, por favor considere la documentación y publicación de los límites de su navegador de la caché. En el mundo de escritorio, donde estos límites suelen ser tan alta como para ser un tema no, la documentación no era necesaria. En el mundo de los móviles, los límites de la caché del navegador son información vital que los desarrolladores web deben tener con el fin de crear sitios web Performant con características atractivas.

Los límites de las nuevas características como localStorage y el caché de la aplicación son bien documentados. Por favor, extender este nivel de la documentación a la caché del componente, así.

Buscar conversaciones: Bloglines | technorati

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

En el salvaje de 25 de junio 2010

25 de junio 2010 a las 10:10 am por Eric Miraglia | En In the Wild | Comments Off

Como siempre, vamos a saber en los comentarios o yuilibrary @ si nos perdimos algo importante.

• YUI 3-basado en la interfaz de usuario de aleación anunció formalmente en la Conferencia de Liferay : Desde el comunicado de prensa : "Como parte de este esfuerzo, Liferay también ha anunciado la inmediata disponibilidad de la interfaz de usuario de aleación de Liferay . Desarrollado en colaboración con YUI de Yahoo proyecto, aleación de la interfaz de usuario proporciona un conjunto de componentes de interfaz de usuario ricas para la creación rápida de fácil uso de portlets, widgets y aplicaciones web. Interfaz de usuario de aleación se refiere a las complejidades de la CSS, HTML y Javascript, liberando a los desarrolladores a centrarse en los requerimientos del negocio y la funcionalidad. Interfaz de usuario de aleación también ayuda a resolver algunos comunes cross-browser problemas de compatibilidad que normalmente consumen los recursos del proyecto. La nueva biblioteca no requiere un portal y se puede utilizar para desarrollar componentes para cualquier aplicación Web. Liferay Portal estandarizará su front-end estructura en torno a la interfaz de usuario de aleación, la ampliación de la simplicidad y capacidades de las modernas soluciones empresariales basadas en portales. Interfaz de usuario de aleación representa una nueva capacidad para los desarrolladores web para simplificar el desarrollo de interfaces de usuario ricas ", dijo Brian Chan, Liferay el creador del portal y Arquitecto Jefe de Software. "Estamos muy contentos de haber trabajado en esto con el equipo de Yahoo y siento que será un gran activo para ayudar a los desarrolladores con sus soluciones." 'Todos los componentes de interfaz de usuario de aleación son ahora fácilmente disponibles a la comunidad en el YUI YUI 3 Galería .
• CarPrices.com AutoFusion lanza el uso de YUI 3.1.1 : YUI 3 Galería colaborador Josh Lizárraga ha estado trabajando con Autofusion Inc. en el nuevo proyecto de CarPrices.com , construido con una serie de YUI 3.1.1 utilidades y widgets. Josh tendrá más información sobre este proyecto en un puesto YUIBlog futuro.
  
• Descargar Erez Zukerman Squad Asesora JS Devs que hay que vigilar Crockford de YUI Theater : Escribe Erez: " Douglas Crockford es un genio. En serio - el tipo es brillante. Él está sirviendo actualmente como arquitecto de Yahoo! 's jefe de JavaScript, inventó JSON (un formato ampliamente usado de intercambio de datos), que es parte del comité de ECMAScript (los chicos establecen el estándar de JavaScript) y tiene un conocimiento muy amplio de la historia general de la programación idiomas e informática. Recientemente, Crockford dio cinco conferencias acerca de JavaScript, como parte de Yahoo! 's Theater YUI . Estos están disponibles de forma gratuita, y son más de cinco horas de duración (más como de seis a siete horas en total, creo). ¿Qué es lo bueno de estas conversaciones es que Crockford realmente le da una vista de pájaro sobre el tema; la primera hora es sólo la historia, y es realmente fascinante. Es por todo el lugar, empezando por el telar de Jackquad , a través de por qué tenemos tanto una eliminación y una tecla de retroceso en nuestros teclados, todo el camino a los lenguajes de programación modernos y JavaScript. "Para más de los recursos favoritos de Erez de JavaScript, echa un vistazo a su cargo , o dirigirse a la Crockford JavaScript en la página de vídeos más recientes de Douglas (con muchos más llenar la segunda columna de YUI Theater ).
  
• Felicidades a Matt Snider y sus amigos en el YUI Mint.com 2-basado, ganadores de un Webby 2010 : ¡Felicitaciones a Matt Snider . y los otros ingenieros destacados en el frontend Mint.com para su bien merecido premio Webby 2010 en la categoría de Servicios Financieros Casa de la Moneda ha sido YUI 2-basado desde el principio , y Matt sigue siendo un gran contribuyente al proyecto YUI . Usted puede ver cinco palabras de Matt discurso de aceptación en YouTube sobre .
  
• Módulo Dion Ajaxian de Almaer Comentarios Caridy Patiño Mayea de precarga Galería de YUI 3 : Dion tiene un buen puesto para arriba en Ajaxian revisar módulo de precarga Caridy Patiño Mayea para la obtención previa de los activos y almacenamiento en caché , una entrada de YUI 3 Galería que él escribió acerca de las últimas en YUIBlog .
  
• Con las cuadrículas YUI con Movable Type (por @ foxxtrot) : YUI colaborador Jeff Craig escribió sobre su experiencia de la conversión de un blog de ​​Movable Type para YUI Grids 2: "Así que, como cualquiera que haya leído mi blog antes, verás que el fin de semana He actualizado mi plantilla de blog para utilizar rejillas YUI y YUI3 para el JavaScript. Al cambiar lejos de las plantillas de MT (o las plantillas que eran estándar al instalar y configurar las primeras versiones de MTOS 4), que fue capaz de reducir el pageweight HTML cerca de la mitad maldita. Las plantillas de los viejos eran muy div-pesado, y tenía un montón de código adicional. Sobre todo, la decisión fue impulsada por el deseo de hacer de nuevo la sensación visual de mi blog, y me sentí que yo pueda escribir así en Grids YUI mientras lo hago. "
• Nate Schutta Compara YUI y Dojo para DevelperWorks IBM : Nate Schutta escribir para IBM developerWorks compara YUI 2.xy Dojo en un nuevo post. Si bien nos centramos más en la línea de código YUI 3.x en estos días, el artículo de Nate tiene algunas directrices útiles para quienes estén pensando en las bibliotecas de JavaScript, y de tomar una decisión para su negocio o proyecto. En primer lugar - ¿por qué YUI o Dojo?

  Con excelentes opciones tantos a su disposición, ¿por qué se tiene en cuenta YUI o Dojo? En una palabra: integridad. A diferencia de otras soluciones que involucran a las bibliotecas adicionales o plug-ins, Dojo y YUI tiene todo (y más) que el actual ingeniero de front-end que pueda desear. Mientras que eso es tanto una bendición como una maldición, si usted está en el mercado de una ventanilla única para sus necesidades de Ajax, se trata de dos contendientes poderosos. Además de una gran cantidad de ayudantes de JavaScript y los servicios públicos, tanto de primer nivel ofrecen widgets y controles-más allá de la paleta limitada del navegador estándar.

  Nate consejos sobre los criterios generales de selección de la biblioteca es útil:

  • ¿Qué quieres de ella? ¿Está buscando un reemplazo completo de casi todos los elementos de la interfaz de la página, o simplemente estás buscando algo para tomar un poco de las molestias de la programación de JavaScript?
  • ¿Qué tan fácil es el código para leer? A pesar de enormes mejoras en la documentación en los últimos años, las probabilidades son que usted tendrá que cavar en el código en algún momento. Antes de comprometerse a una biblioteca, pasar algún tiempo hasta las rodillas en la fuente. ¿Es fácil de entender, o no, incluso el autor original tiene problemas con él?
  • ¿Qué tan buena es la documentación? Un código limpio y fácil de leer puede hacer por menos-que-estelares documentos, pero nada le ayuda a empezar bien como tutoriales y ejemplos. Echar un vistazo al wiki o página web, y ver lo que tienen que ofrecer. Son los ejemplos claros y fáciles de seguir? ¿Una rápida búsqueda en Google te llevará al papel que le corresponde de su material?
  • ¿Cuál es la comunidad como la que rodea a la biblioteca? Echa un vistazo a las listas de correo. ¿Hay una gran cantidad de tráfico? ¿Las personas nuevas tratado con respeto o burla? Ha sido actualizado el código recientemente, o fue la última versión desde hace varios años?
  • ¿Se puede obtener ayuda? Aunque esto está relacionado con los bits anteriores acerca de la comunidad, siempre es valioso para mirar a su alrededor la comunidad de desarrollo y ver quién está usando qué. Echa un vistazo a las bolsas de trabajo para tener una idea de que las bibliotecas se están presentando con frecuencia en hojas de vida.

Buscar conversaciones: Bloglines | technorati

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

YUI: Horario Viernes 25 de Junio

23 de junio 2010 a las 3:07 pm por Luke Smith | En Desarrollo | Comments Off

La última entrega de YUI: Horario de apertura será este viernes, 25 de junio.

La semana pasada, Eduardo Lundgren nos presentó a algunos de los grandes AlloyUI módulos añadidos recientemente a la Galería. El debate se centró en la instanciación, configuración, las decisiones de desarrollo, y un poco de historia de su TreeView módulo. Pero eso fue sólo el comienzo. También exploramos la IO , Nodo , y la forma de validación de los módulos y pasó algún tiempo en algunos de los estilos visuales disponibles. Eduardo incluso nos dio un adelanto del nuevo Liferay, Inc. portal, alimentado por todo ese trabajo duro. Realmente de primera clase de trabajo.

Dicho todo esto, es difícil decir si el espectáculo-y-decir o que la conversación fue el techo real. Gran código relacionado con el contenido de un lado, había un montón de buenos comentarios y la discusión acerca de la colaboración de la comunidad, la naturaleza de la Galería, y cómo lo podemos hacer y YUI mejor. Así que muchas gracias a todo el mundo en la llamada!

Esta semana, vamos a incursionar un poco en tanto en el mundo de desarrolladores en bruto, así como el mundo de diseño. Caridy Patiño está de vuelta con nosotros para hablar de su cuaderno de eventos módulo que se presentó aquí esta mañana . Vamos a hacer una revisión de código y discutir el paso de la configuración que tiene que hacer antes de YUI es aún cargado. Así es: pura y sin adulterar scripting DOM. Es posible que desee usar un casco.

A continuación, vamos a seguir adelante con el proceso de diseño de la piel también matizada con Jeff Conniff, el yahoo responsable de la actual variedad de deslizante se ven y se siente. Él nos guiará a través de su proceso de construcción de los activos visuales y mostrar cómo se puede tener los mismos PSD y crear fácilmente los activos de color temáticas que se ajustan en su paleta de sitio. Aquí están los archivos de Photoshop si quiere seguir el juego. También voy a hablar de algunas de las decisiones tomadas en la construcción de la estructura CSS y DOM de Slider.

Estamos de vuelta en el día y la hora habitual de la semana: Viernes 10 a.m.-12 p.m. PDT. Hay un código nuevo asistente para la llamada de conferencia, pero por lo demás, los detalles de la conexión son los mismos, como de costumbre.

1. Marque 1-888-371-8922 para (no estadounidenses participantes, enviarme un correo electrónico a un número local)
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)

También he creado un hilo en el foro de este Horario de atención para que podamos empezar la discusión con anticipación!

Además, como siempre, usted puede mantenerse al día con el calendario de eventos y otros temas siguiendo @ yuilibrary en Twitter o suscribirse al Calendario de Eventos YUI .

Esperamos verte allí!

Buscar conversaciones: Bloglines | technorati

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

En la galería de YUI 3: Módulo Caridy Patiño Mayea del Evento Carpeta brinda apoyo para el evento el enlace anticipado y por eventos de carga del módulo

23 de junio 2010 a las 9:25 am por Caridy Patiño | En Desarrollo , YUI 3 Galería | 1 comentario

En este artículo se presenta a mi módulo de Cuaderno de eventos , publicado recientemente en la Galería de YUI 3.

YUI 3 es conseguir una buena tracción en la comunidad de desarrolladores, con la adopción significativa de la última versión 3.1.1 y una enorme inyección de proyectos nuevos e innovadores en el YUI 3 Galería . Muchos desarrolladores están consiguiendo sus cabezas alrededor de la naturaleza en la demanda de YUI 3 y comenzando a aprovechar esas capacidades en sus diseños. Este método tiene grandes ventajas, pero también puede presentar algunas dificultades.

Uno de estos retos es captar las interacciones del usuario inicial. A pesar de que el navegador se inicia la prestación de la página, queremos que el usuario sea capaz de empezar a interactuar con elementos de la página. En muchos casos, estas interacciones pueden ocurrir antes de activar el proceso de inicialización (incluido el embargo de los detectores de eventos) se ha completado.

En muchos casos se puede mejorar el código de inicialización sólo mediante el establecimiento de los detectores de eventos y luego agregar la lógica para la carga de las piezas que necesita para cada interacción con el usuario. Recientemente, los ingenieros de Facebook habló sobre un enfoque similar para mejorar el proceso de carga - ver la entrevista de Rey Bango en JSConf. Aquí está un ejemplo de cómo esta técnica podría funcionar en YUI 3:

  <Script src = "http://yui.yahooapis.com/combo?3.1.1/build/yui/yui-min.js y
 
	 3.1.1/build/oop/oop-min.js y 3.1.1/build/event-custom/event-custom-base-min.js y
	 3.1.1/build/event/event-base-min.js y 3.1.1/build/dom/dom-base-min.js y
	 3.1.1/build/dom/selector-native-min.js y 3.1.1/build/dom/selector-css2-min.js y
	 3.1.1/build/node/node-base-min.js "> </ script>
 
 YUI (). Utilizar ("caso base", la función (y) {
     / / Espera hasta que el usuario se centra en un elemento de entrada para iniciar la carga de los activos
     Y.on ("click", function (e) {
 
       Y.use ('anim', 'io', function () {
           / / Cargar un contenido remoto y lo mostrará mediante una animación aquí
       });
 
       e.halt (); / / detener la propagación
     }, "Demo");
 }); 

Esto introduce una cierta complejidad en el código porque no oyentes sólo tienen que lidiar con la interacción del usuario, sino también con una lógica de carga. Otra desventaja de este enfoque es que usted todavía tiene que cargar algo de código JavaScript en la parte superior (en este caso las semillas de YUI, la utilidad de eventos, y las dependencias de algunos de ellos) con el fin de definir al menos el oyente y la lógica de carga para coger las primeras medidas. Por lo tanto, vamos a considerar esto como dos diferentes casos de uso:

• La captura de las primeras interacciones de los usuarios
• Facilitar la naturaleza en la demanda de algunas interacciones de los usuarios

Para atender estas necesidades que he creado un nuevo módulo para YUI 3 . Mi principal objetivo ha sido crear un componente que funciona sin afectar a la lógica de su aplicación. Este nuevo módulo se llama " Galería del evento aglutinante "y ahora está disponible a través del gestor de YUI.

La captura de las primeras interacciones de los usuarios

El objetivo principal de esta función es garantizar que las interacciones de los usuarios están haciendo cola hasta que los detectores de eventos se inician.

Veamos un ejemplo de ligante de eventos :

  YUI ({
     / / Galería de última generación de este módulo
     Galería de fotos: la galería-06.07.2010-17-52 '
 }). Usar (la galería del evento aglutinante ',' caso ', function (Y) {
 
     Y.on ('click', function (e) {
 
         / / Hacer tus cosas aquí
         e.halt (); / / detener la propagación de eventos si quieres ...
 
     }, '# Demo');
 
     / / Extraer las primeras interacciones de los usuarios
     Y.EventBinder.flush ("clic");
 
 }); 

En este ejemplo, YUI Loader intentará cargar las gallery-event-binder y event módulos on-demand, y una vez que ambos están listos junto con sus dependencias, el código dentro de la función de devolución de llamada (tercer argumento) será ejecutado. Durante la ejecución, un oyente se establece para un elemento con id=demo . El truco aquí es que una vez Y.EventBinder.flush('click') se llama, el sistema eliminará algunos de los eventos de clic que pueden haber ocurrido antes de que este código de inicialización se ejecuta.

La configuración

Esta técnica requiere una configuración adicional, en particular la definición de YUI_config como una variable global para ajustar la ejecución de YUI. No te preocupes, es muy sencillo. Veamos un ejemplo, en los detalles:

 
 YUI_config = {
     / / Configuración estándar de YUI_config
     se combinan: true,
     Filtro: 'min',
 
     / / Evento de configuración aglomerante comienza aquí
     eventbinder: {
         / / Manejador de eventos para almacenar los eventos que desea la reexpedición.
         fn: function (e) {
             var = carpeta de YUI_config.eventbinder,
                 filter = / yui3 evento aglutinante /,
                 contenedor = (e.target | | e.srcElement),
                 info = {
                     objetivo: el envase,
                     Tipo: e.type
                 };
 
             / / Busca un elemento con la clase yui3 evento aglutinante
             mientras que (&& contenedores! filter.test (container.className)) {
                 contenedor = container.parentNode;
             }
 
             if (contenedor) {
                 (Binder.q binder.q = | | []) push (información).;
 
                 / / Impedir la acción del navegador por defecto para este evento
                 if (e.preventDefault) {
                     e.preventDefault ();
                 }
                 retorno (e.returnValue = false);
             }
         },
         / / Interfaz para detectar eventos específicos
         listenFor: function (tipo) {
             var d = documento;
             / / Antes de las cargas de la biblioteca, tenemos que lidiar con inconsistencias de navegación
             if (d.addEventListener) {
                 d.addEventListener (tipo, this.fn, false);
             Else {}
                 d.attachEvent ('on' + tipo, this.fn);
             }
 
             devolver este;
         }
     }
 };
 / / Añadir eventos al proceso de seguimiento
 YUI_config.eventbinder.listenFor ("clic");

Este código debe ser incluido en la parte superior de la página. Será sólo unos pocos bocados, una vez que minify el objeto de configuración. Recomiendo el uso de un cacheable (externo) de archivo para la producción y su inclusión en la sección de la cabeza en sus páginas. Usted puede leer más acerca de YUI_config y las diferentes configuraciones que se pueden manipular a través de este objeto en la documentación de la API oficial .

Usted puede modificar esta configuración para adaptarse a usted mejor, y definir los eventos que le interesan también. En el ejemplo anterior, hemos añadido un 'clic' a la lista de control (última línea). Usted puede agregar varios eventos a la lista de vigilancia con el encadenamiento de:

  YUI_config.eventbinder.listenFor ("clic") listenFor ('KeyUp') listenFor ("mouseover")..; 

¿Cómo funciona esta característica?

Una vez que la configuración (es decir, YUI_config ) lógica se ejecuta, junto con la llamada a YUI_config.eventbinder.listenFor , un detector para un tipo de evento específico será definido. Sólo las citas que hasta la burbuja serán controlados como el oyente será definido por el document elemento. Cuando una interacción con el usuario es sorprendido en este nivel, se analizará, en particular de verificar si el elemento de destino o de cualquiera de sus ascendientes tiene nombre de clase yui3-event-binder . Si es así, el evento se añaden a una cola y el comportamiento predeterminado para ese evento serán prevenidas. Esta técnica proporciona una manera fácil de controlar los tipos específicos de interacción en áreas específicas de la página.

Cuando se ejecuta este código, los oyentes para los eventos del tipo especificado o los tipos se añaden al document , por lo que cuando estos eventos ocurren y la burbuja hacia arriba (este tipo de eventos únicos que los monitores de la burbuja), que se detuvo y se almacena su información en una cola de procesamiento . Más tarde, en su use() de devolución de llamada cuando la inicialización ha terminado, simplemente llame a Y.EventBinder.flush la reexpedición almacenados todos los eventos de clic como si hubieran ocurrido en ese momento-por cortesía de el módulo de simulación de eventos.

Facilitar la naturaleza en la demanda de algunas interacciones de los usuarios

El objetivo principal de esta función es ayudar a los desarrolladores para definir la lógica de la carga sobre la base de las interacciones del usuario.

He aquí otro ejemplo de ligante caso :

 
 YUI ({
   módulos: {
     "Mi-custom-módulo ': {
       fullpath: '. / mi-custom-module.js'
     }
   }
 }). Usar (la galería del evento aglutinante ',' nodo ', function (Y) {
 
   / / Establecer una escucha de '# demo' y se basan en "mi-custom-módulo 
   / / Para manejar ese evento en particular.
   Y.EventBinder.on ('click', 'mi-custom-módulo', '# demo');
 
   / / Establecer una escucha de delegado para todos los anclajes en una lista y se basan  
   / / En "mi-custom-módulo" y "mi-otro módulo-'para manejar esos eventos particulares
   Y.EventBinder.delegate ('click', ['mi-otro módulo-'], '# milista', 'li a');
 
 });

Aquí usamos Y.EventBinder.on y Y.EventBinder.delegate para definir algunos oyentes. Estos dos métodos de envoltura Y.on y Y.delegate para conducir la lógica de carga a través de una interacción del usuario. Esto nos permite diferir la carga de la funcionalidad específica de una página hasta que el usuario intenta utilizar una característica particular.

En este caso, cuando un usuario hace clic en uno de los elementos, cargar uno o más módulos personalizados de YUI que implementan todas las funciones asociadas con ese clic con el botón en particular. Una vez que los módulos estén disponibles (y los oyentes se establecen nuevas), el aglutinante sirve para lavar el caso de que estaba en suspenso durante el proceso de carga para preservar el estado de la acción.

Esta función no requiere ninguna configuración inicial. Ambas características suceso Binder se puede utilizar al mismo tiempo para cubrir los primeros y bajo demanda por el usuario interacciones. En este caso, es necesario definir la configuración, a continuación, establecer los oyentes a la carta, y, finalmente, eliminar los primeros acontecimientos.

Here's an end-to-end event binder example :

 
// configuration
YUI_config = { /* your custom event-binder configuration here */ };
YUI_config.eventbinder.listenFor('click')
 
 / / Inicialización
YUI({
  modules: {
    'my-custom-module': {
      fullpath: './my-custom-module.js'
     }
   }
}).use('gallery-event-binder', function(Y) {
  
  Y.EventBinder.delegate('click', ['my-custom-module'], '#doc', '.yui3-event-binder a');
  Y.EventBinder.flush('click');
 
 });

A more advanced configuration

You can modify the fn function in your configuration to be more selective about which events to queue and you can store more information about the events. Additionally adds a yui3-waiting class to the click target which we style in CSS to display a loading spinner:

 
YUI_config = {
    // standard YUI_config configuration
    combine: true,
    filter: 'min',
 
    // event binder configuration starts here
    eventbinder: {
        // set of options that should be preserved for every event (all optional)
        eventProperties: [
            "ctrlKey", "altKey",
            "shiftKey", "metaKey",
            "keyCode", "charCode",
            "screenX", "screenY",
            "clientX", "clientY",
            "button",
            "relatedTarget"
         ],
 
        // listener callback function
        fn: function(e) {
            var binder = YUI_config.eventbinder,
                props = binder.eventProperties,
                filter = /yui3-event-binder/,
                target = (e.target || e.srcElement),
                container = target,
                info = {
                    target: target,
                    type : e.type
                 },
                 i;
 
            if (target.nodeType === 3) {
                // target is a text node, so use its parent element
                target = target.parentNode;
             }
 
            // look for an element with the class yui3-event-binder
            while (container && !filter.test(container.className)) {
                container = container.parentNode;
             }
 
            if (container) {
                target.className += ' yui3-waiting';
 
                // back up the event properties to simulate the event later on
                for (i = props.length - 1; i >= 0; --i) {
                    info[props[i]] = e[props[i]];
                 }
 
                (binder.q = binder.q || []).push(info);
 
                // prevent the default browser action for this event
                if (e.preventDefault) {
                     e.preventDefault ();
                 }
                return (e.returnValue = false);
             }
         },
 
        listenFor: function(type) {
            var d = document;
 
            if (d.addEventListener) {
                d.addEventListener(type, this.fn, false);
             Else {}
                d.attachEvent('on' + type, this.fn);
             }
 
             devolver este;
         }
     }
 };
// add events to the monitoring process
YUI_config.eventbinder.listenFor('click');

Check out this event binder example to see this advanced configuration in action.

Conclusión:

For high performance web applications, it's important for pages to load and become responsive quickly. To accomplish this, we have to rely on on-demand loading techniques. Once you start using them, it's equally important to control user interactions that can happen before the corresponding code for an action become available.

Event Binder (gallery-event-binder) provides friendly APIs to deal with both use-cases without you having to change your application logic. It can be applied to any YUI 3 application without introducing extra complexity to your code.

Buscar conversaciones: Bloglines | technorati

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

Using the YUI 3 Calendar Date Selector from Alloy

June 18, 2010 at 10:46 am by Eric Miraglia | In Development , YUI 3 Gallery | 6 Comments

The Alloy components (contributed by Nate Cavanaugh and Eduardo Lundgren from Liferay) in the YUI 3 Gallery are simple to use. This example illustrates the use of the Alloy calendar to progressively enhance a set of select elements for date selection.

Let's start with the markup — the HTML that will be on the page and functioning regardless of whether JavaScript is enabled. Alloy's Calendar module does not require this markup; you can feed it an empty element and it will create the select elements for you in the event that your use case would not benefit from progressive enhancement.

 <div id="calendar">
	<select class="yui3-datepicker-month" name="month" id="monthselect">
		<option value="0">
			 Enero
		 </ Option>
		<option value="1">
			 Febrero
		 </ Option>

 ...

	 </ Select>

        <select class="yui3-datepicker-day" name="day" id="dayselect">
		<option value="1">
			 1
		 </ Option>
		 <option value="2">
			 2
		 </ Option>

 ...

	 </ Select>

        <select class="yui3-datepicker-year" name="year" id="yearselect">
		<option value="2009">
			 2009
		 </ Option>

 ...

	 </ Select>
 </ Div> 

With this markup in place (or with just an empty root element if we aren't progressively enhancing existing form fields), we bring in the Alloy Calendar module with datepicker selection support from the YUI 3 Gallery . This requires us to have YUI 3 on the page and then to follow the configuration step outlined on the module's Gallery page .

 <script src="http://yui.yahooapis.com/3.1.1/build/yui/yui-min.js"></script>
<script>
YUI({
	// All of this configuration information can be cut-and-pasted from the Gallery entry for
	// this module: http://yuilibrary.com/gallery/show/aui-calendar-datepicker-select
    gallery: 'gallery-2010.06.07-17-52',
    modules: {
        'gallery-aui-skin-base': {
            fullpath: 'http://yui.yahooapis.com/gallery-2010.06.07-17-52/build/gallery-aui-skin-base/css/
							gallery-aui-skin-base-min.css',
            type: 'css'
         },
        'gallery-aui-skin-classic': {
            fullpath: 'http://yui.yahooapis.com/gallery-2010.06.07-17-52/build/
							gallery-aui-skin-classic/css/
							gallery-aui-skin-classic-min.css',
            type: 'css',
            requires: ['gallery-aui-skin-base']
         }
     }
}).use('gallery-aui-calendar-datepicker-select', function(Y) {
    var datePickerSelect = new Y.DatePickerSelect({
		displayBoundingBox: '#calendar',
		dateFormat: '%m/%d/%y',
		yearRange: [ 2009, 2012 ],
		dayField: Y.one("#dayselect"),
		dayFieldName: "day",
		monthField: Y.one("#monthselect"),
		monthFieldName: "month",
		yearField: Y.one("#yearselect"),
		yearFieldName: "year"
	}).render();
 });

 </ Script> 

Here's a live version of this simple example .

Es tan simple como eso. The configuration properties for datePickerSelect are lucidly defined in the Alloy documentation . In this example, the properties are used to set the root element, format the date, set the date range, and then wire up our existing select elements to the widget instance so that it knows which form fields to use for progressive enhancement. In practice, only the root element ( displayBondingBox ) is a required property.

Check out the YUI 3 Gallery roster for a full list of the Alloy UI contributions .

Buscar conversaciones: Bloglines | technorati

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

Implementation Focus: YUI 3 Powering Autofusion's ResearchPro

June 18, 2010 at 9:00 am by Josh Lizarraga | In Development | Comments Off

About the author: Josh Lizarraga is a YUI Contributor and frontend developer located in San Diego, California. He uses YUI to build rich frontend interfaces and Ajax applications for Autofusion, Inc. , a San Diego firm that offers web solutions to the automotive industry in the United States and Canada. When he's not on the clock, Josh enjoys contributing to the YUI project with test cases and Gallery modules.

Sobre el Proyecto

In addition to serving industry professionals, Autofusion provides end-user information resources via our CarPrices.com sister-site. “ResearchPro” is the name we've bestowed on our brand new car research application, which allows the user to quickly and easily find everything there is to know about a potential new car purchase.

Researching a new car before you buy is typically a daunting yet necessary experience, and the current options available to consumers are not very user-friendly. ResearchPro attempts to remedy these issues with a simple, guided approach to car research. We also take the experience one step further, allowing customers to receive a free quote on their dream car from local dealers.

¿Por qué YUI?

We started using YUI 2 for all of our frontend development about two years ago, and haven't looked back. YUI's focus on application development makes it a no-brainer for Autofusion, as we provide many embeddable web apps and widgets to our customers.

Over the years we have used just about every YUI 2 component there is in both our client web properties and our internal tools. YUI's proven track record and incredible documentation really set it apart from the other libraries we've worked with. The refinements to the library offered by YUI 3 made it an easy choice for this project.

How YUI is Utilized in the Project

ResearchPro makes use of several YUI 3 components, namely IO , JSON , Node , Event , Animation , and even the beta Slider widget. We're also using the selector-css3 and event-mouseenter modules, as well as a custom module that handles the JSON communication with the backend.

Challenges and Benefits of Using YUI 3

Migrating from YUI 2 to YUI 3 was both the largest challenge and the largest benefit during ResearchPro's development. Working with Node instances instead of DOM nodes directly can take some adjusting to at first, but we quickly found that this excellent abstraction greatly reduces the amount and complexity of the code for a given task. Likewise, the chainability of YUI 3 methods offers some great syntactic sugar that is hard to live without.

The primary challenge of the YUI 3 migration was and continues to be beta bugs. The first YUI 3 beta was released a few months before we started development, and we took that opportunity to start this project with the new codeline. We wanted to be familiar with YUI 3 once it replaces YUI 2 in our workflow down the road. During development, we discovered and reported several bugs, some of which are still being worked out today.

What's Next for Autofusion?

We are always developing new products with YUI and revising our existing offerings to incorporate YUI on the frontend. Our online inventory solution is powered by YUI 2, and we're currently planning a refined version of the product that will use YUI 3 in its place.

Our inventory interface makes heavy use of the Container module family, so hopefully by the time we start development YUI 3 will have implementations of Panel and Dialog. We've been very pleased with the rapid growth of features, and expect YUI to be our frontend toolkit of choice for years to come.

Buscar conversaciones: Bloglines | technorati

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

YUI: Open Hours, Wed June 16th

June 15, 2010 at 12:26 am by Luke Smith | In Development | 2 Comments

It's time again for YUI: Open Hours ! A change of schedule this week, though. The call will be on Wednesday .

I want to start by sending a huge thanks to Iliyan Peychev, Andrew Bialecki , Matt Snider , and Jacob Fogg for featuring their Gallery widgets in the last Open Hours. From Matt's game UI inspired Radial Menu to Iliyan's full featured Accordion , it was a great exploration of the types of UI tools you can find (or create) in the Gallery today as well as a study in different ways to use YUI 3 to solve UI challenges. You can find links to the modules in the May 21st Open Hours post , and a sampling of some of the interesting points from the discussion in the comments .

This week, hot on the heels of their huge YUI 3 Gallery contribution , Nate Cavanaugh and Eduardo Lundgren of Liferay, Inc. will be joining us to introduce us to some of the new AlloyUI modules. Esta es una gran cosa. We've been working with these guys for months to get their 65 modules into the Gallery. That's right, 65 modules! All created by just Nate and Eduardo. Talk about productive.

Obviously we'll barely have time to scratch the surface of all the AlloyUI modules, but we will do a quick overview of some of the most interesting or popular ones and cover some “Getting started” code. There's such a variety of modules, there will be something for everyone.

• For YUI 3 newcomers or folks that have been waiting for the YUI 2 widgets to be migrated, there are now a lot more options to check out.
• For people wanting to take those first steps creating something in YUI 3, there are now more things to write plugins for, patch, or extend.
• For seasoned component developers, there's now a lot more implementation code to reference for evolving conventions and components to collaborate on.
• For more complex app developers, you can get a sense of one team's strategy for code submodularization and approach for building and packaging modules in a larger or more complex application.

Nate and Eduardo are open to whatever questions you have, so the conversation can go however deep, and in whichever direction you want. If you have any questions about a particular module or about anything else, ask away.

We're changing up a little this week and moving Open Hours to Wednesday . The time will be the same as before, though (10am – 12pm PDT), and the connection details are also the same:

1. Dial in to 1-888-371-8922 (non-US participants, email me for a local number)
2. Enter the attendee code 4718 8953#
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)

And as always, you can keep up to date with the upcoming schedule and topics by following @yuilibrary on Twitter or subscribing to the YUI Event Calendar .

Esperamos verte allí!

Buscar conversaciones: Bloglines | technorati

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