Este documento presenta sobre componentes web y el framework Polymer. Introduce los conceptos clave de la plataforma web orientada a componentes, incluyendo el modelo de encapsulamiento Shadow DOM, el modelo de renderizado utilizando templates, el modelo de extensión Custom Elements y el modelo de modularización HTML Imports. También describe los nuevos roles requeridos como diseñador de componentes, programador de componentes y maquetador de componentes.
La Web está evolucionando a pasos agigantados en los últimos tiempos. Una de las direcciones de avance en este sentido apunta hacia su modularización. En lugar de construir pesadas aplicaciones monolíticas, parece estar más en sintonía con los principios arquitectónicos de la Web hacer un desarrollo dirigido por la construcción de componentes Web sencillos, atómicos y funcionales que fomenten su reutilización transversal y puedan utilizarse como etiquetas de autor personalizadas para articular soluciones elaboradas. Pero más allá de limitarnos a construir componentes Web y utilizarnos de manera conjunta en una página huesped, la orientación a componentes exige encontrar cierto grado de interoperabilidad entre los mismos para ofrecer una sensación de continuidad en su uso al usuario final.
De acuerdo a esta idea, en esta charla comenzaremos haciendo una revisión de la tecnología utilizada para la construcción de componentes Web según las especificaciones estándar de la W3C y del WWG, haciendo uso de la Plataforma de soporte Polymer de Google como implementación nuclear de referencia. Esto nos dará pie para presentar el problema de cómo puede abordarse la construcción de soluciones Web orientadas a componentes para ofrecer niveles de interoperabilidad adecuados. Ofreceremos, en este sentido, algunas soluciones arquitectónicas al respecto y presentaremos ejemplos de su aplicabilidad práctica en contextos realistas.
Cada lenguaje, cada tecnología, cada paradigma de programación persigue siempre la reutilización de código. En la comunidad de desarrollo se habla frecuentemente de DRY (Don’t Repeat Yourself) o WORE (Write Once Run Everywhere). Pero estos manidos mantras se quedan frecuentemente en una mera declaración de principios.
El código desarrollado para su reutilización no es capaz de reubicarse en otros contextos arquitectónicos de aquellos para los que fue inicialmente diseñado. Las capacidades de meta-programación de JavaScript le convierten en un lenguaje flexible y lo suficientemente plástico como para adaptarse dinámicamente a cualquier solución construida.
En esta charla exploramos como construir programas que se modifiquen a si mismos para resolver estos problemas y hablaremos de modelos de programación basados en componentes de software.
La reutilización ha sido desde siempre uno de los objetivos más perseguidos dentro de la ingeniería del software. La idea de convertir los procesos de construcción de aplicativos en algo automatizable, sencillo y económico siempre ha estado ahí en la cabeza de los desarrolladores. Pero, de manera recurrente, esta iniciativa se ha dado de bruces con los inamovibles mimbres de unos paradigmas de programación demasiado inflexibles a este respecto.
Sin embargo, lenguajes como Javascript se prestan mucho más a hacer del desarrollo de código un ejercicio de verdadera reutilización. A lo largo de esta charla explicaremos cuáles son las barreras paradigmáticas que suelen impedir la reutilización y cómo y en qué sentido JavaScript consigue soslayarlas con éxito. Asimismo presentaremos una colección de modelos arquitectónicos basados en Mixins, Traits, Roles, Aspectos, Subjects, etc. que se están usando en proyectos de software actuales con este lenguaje precisamente por las bondades que ellos.
En los últimos tiempos se viene demandando dentro de las comunidades de desarrollo la construcción de arquitecturas reactivas que sean capaces de hacer frente a parámetros de rendimiento y tiempo de respuesta no conocidos hasta el momento. Una arquitectura reactiva es un sistema responsive capaz de reaccionar a tiempo a los requisitos bajo demanda, diseñado para adaptarse elásticamente a sus fluctuaciones variantes, que presenta un comportamiento altamente tolerante a fallos y que se dirige por un procesamiento masivo de mensajes.
Pero más allá de todo esto, las arquitecturas reactivas se han convertido en un modelo de programación basado en transformaciones funcionales para dar soporte a sistemas dirigidos por eventos asíncronamente. En marco del desarrollo de soluciones para Front End, este tipo de aproximaciones está cogiendo tracción debido a lo bien que se adapta al modelo de interacción de la Web. En este contexto, los eventos responden a las interacciones del usuario sobre el agente navegador y la lógica de negocio se expresa como la transformación secuencial y progresiva de los mismos de forma encadenada. A lo largo de esta charla estudiaremos cómo funcionan este tipo de arquitecturas en contraposición con las clásicas soluciones MV* y presentaremos el modelo de desarrollo asociado.
Charla para JS Day Madrid 2015 09/05/2015:
- Video: https://goo.gl/jOm4aN
- Slideshare: http://goo.gl/cnTQw9
- Github: https://goo.gl/as8pdD
Cada lenguaje, cada tecnología, cada paradigma de programación persigue siempre la reutilización de código. En la comunidad de desarrollo se habla frecuentemente de DRY (Don’t Repeat Yourself) o WORE (Write Once Run Everywhere). Pero estos manidos mantras se quedan frecuentemente en una mera declaración de principios.
El código desarrollado para su reutilización no es capaz de reubicarse en otros contextos arquitectónicos de aquellos para los que fue inicialmente diseñado. Las capacidades de meta-programación de JavaScript le convierten en un lenguaje flexible y lo suficientemente plástico como para adaptarse dinámicamente a cualquier solución construida.
En esta charla exploramos como construir programas que se modifiquen a si mismos para resolver estos problemas y discutiremos mecanismos, técnicas y patrones de metaprogramación basados en componentes de software.
Video: http://goo.gl/acVK2t
Slideshare: http://goo.gl/2OChM4
Github: http://goo.gl/29ldtQ
La Web se está orientando a componentes. El objetivo es alcanzar una Web cada vez más madura, dirigida a fomentar la sencillez en las tareas de diseño y construcción, aumentar la rapidez y agilidad de desarrollo y mejorar la productividad general de las soluciones Web. Todo esto se consigue en parte debido al carácter declarativo que confiere la tecnología de componentes Web que, además, permite encapsular un comportamiento complejo, absorber la gestión adaptativa de los contenidos y, a la postre, generar un vocabulario propio de etiquetas de autor que fomenta la reutilización de código desde el front end.
Sin embargo, la comunidad demanda de manera creciente la definición de directrices y buenas prácticas en relación con las actividades de diseño y desarrollo vinculadas a la construcción de soluciones basadas en componentes Web. En esta charla ofreceremos una colección de principios que tienen por objetivo orientar a los equipos implicados en este tipo de proyectos.
La Web está evolucionando y los procesos de desarrollo en relación a la misma también lo hacen. Es una realidad vigente que cada vez más este tipo de soluciones pasarán por la construcción de componentes Web de negocio, etiquetas de autor que extienden el léxico del estándar HTML. Google vehicula esta solución a través del framework Polymer, cuya version 1.0 vio la luz hace pocos meses coincidiendo con la Google I/O 2015.
Pero en esta charla, no nos limitaremos a presentar las novedades de este Framework que pueden leerse directamente en la Web, que también. Hablaremos de los resultados de nuestra investigación en este terreno. Cuáles son los principios de diseño de componentes web, cuál es el modelo adecuado de componentes y cómo debe desarrollarse una arquitectura basada en componentes que cumpla con las necesidades arquetípicas de las soluciones Web y Mobil de hoy en día.
Arquitecturas de Componentes Web. Patrones de ComposiciónJavier Vélez Reyes
La tecnología de componentes web ha supuesto un revulsivo en la forma en la que se desarrollarán soluciones web en los próximos años. Si algo hemos aprendido, en este sentido, es que debemos dejar de construir aplicaciones monolíticas y empezar a pensar en crear componentes Web estratégicamente diseñados para que cubran las necesidades más comunes dentro de este tipo de problemas.
Polymer y los estándares de componentes Web nos proporcionan ya toda una panoplia de herramientas para construir este tipo de soluciones de manera más sencilla. Sin embargo, aun faltan muchos mimbres por establecer. La necesidad de un modelo arquitectónico de referencia se dibuja como una necesidad insoslayable para poder articular soluciones de éxito de esta naturaleza. En efecto una arquitectura nos ofrece un marco prescriptivo preciso donde dar forma a las contribuciones de múltiples partes para crear un catálogo de componentes coherente que pueda ser utilizado por la comunidad para construir soluciones orientadas a componentes web.
En relación a lo anterior, a lo largo de esta charla centraremos nuestra atención en un problema nuclear: ¿Cómo deben articularse los procesos de composición en el marco de esta tecnología? Para responder esta pregunta no debemos olvidar que este nuevo paradigma prescribe un proceso constructivo desarrollado en el ámbito declarativo del lenguaje HTML y no en el espacio programático de JavaScript, dado que así se consiguen procesos de desarrollo más sencillos, ágiles y productivos. En relación a la composición todo esto implica que no sólo debemos esforzarnos por crear componentes visuales que den respuesta a las necesidades recurrentes de interacción en el plano del front sino que, adicionalmente, debemos elaborar un conjunto de componentes dedicado a a estereotipar y encapsular toda aquella lógica de composición más común. De esta manera el desarrollo de soluciones orientadas a componentes web alcanzará su madurez plena al convertir un tedioso proceso constructivo en un ejercicio de confección compositiva asistido por componentes que proporcionan código pegamento. Todo esto se resume en que debemos crear componentes visuales, sí, pero además componentes para componer.
La Web está evolucionando a pasos agigantados en los últimos tiempos. Una de las direcciones de avance en este sentido apunta hacia su modularización. En lugar de construir pesadas aplicaciones monolíticas, parece estar más en sintonía con los principios arquitectónicos de la Web hacer un desarrollo dirigido por la construcción de componentes Web sencillos, atómicos y funcionales que fomenten su reutilización transversal y puedan utilizarse como etiquetas de autor personalizadas para articular soluciones elaboradas. Pero más allá de limitarnos a construir componentes Web y utilizarnos de manera conjunta en una página huesped, la orientación a componentes exige encontrar cierto grado de interoperabilidad entre los mismos para ofrecer una sensación de continuidad en su uso al usuario final.
De acuerdo a esta idea, en esta charla comenzaremos haciendo una revisión de la tecnología utilizada para la construcción de componentes Web según las especificaciones estándar de la W3C y del WWG, haciendo uso de la Plataforma de soporte Polymer de Google como implementación nuclear de referencia. Esto nos dará pie para presentar el problema de cómo puede abordarse la construcción de soluciones Web orientadas a componentes para ofrecer niveles de interoperabilidad adecuados. Ofreceremos, en este sentido, algunas soluciones arquitectónicas al respecto y presentaremos ejemplos de su aplicabilidad práctica en contextos realistas.
Cada lenguaje, cada tecnología, cada paradigma de programación persigue siempre la reutilización de código. En la comunidad de desarrollo se habla frecuentemente de DRY (Don’t Repeat Yourself) o WORE (Write Once Run Everywhere). Pero estos manidos mantras se quedan frecuentemente en una mera declaración de principios.
El código desarrollado para su reutilización no es capaz de reubicarse en otros contextos arquitectónicos de aquellos para los que fue inicialmente diseñado. Las capacidades de meta-programación de JavaScript le convierten en un lenguaje flexible y lo suficientemente plástico como para adaptarse dinámicamente a cualquier solución construida.
En esta charla exploramos como construir programas que se modifiquen a si mismos para resolver estos problemas y hablaremos de modelos de programación basados en componentes de software.
La reutilización ha sido desde siempre uno de los objetivos más perseguidos dentro de la ingeniería del software. La idea de convertir los procesos de construcción de aplicativos en algo automatizable, sencillo y económico siempre ha estado ahí en la cabeza de los desarrolladores. Pero, de manera recurrente, esta iniciativa se ha dado de bruces con los inamovibles mimbres de unos paradigmas de programación demasiado inflexibles a este respecto.
Sin embargo, lenguajes como Javascript se prestan mucho más a hacer del desarrollo de código un ejercicio de verdadera reutilización. A lo largo de esta charla explicaremos cuáles son las barreras paradigmáticas que suelen impedir la reutilización y cómo y en qué sentido JavaScript consigue soslayarlas con éxito. Asimismo presentaremos una colección de modelos arquitectónicos basados en Mixins, Traits, Roles, Aspectos, Subjects, etc. que se están usando en proyectos de software actuales con este lenguaje precisamente por las bondades que ellos.
En los últimos tiempos se viene demandando dentro de las comunidades de desarrollo la construcción de arquitecturas reactivas que sean capaces de hacer frente a parámetros de rendimiento y tiempo de respuesta no conocidos hasta el momento. Una arquitectura reactiva es un sistema responsive capaz de reaccionar a tiempo a los requisitos bajo demanda, diseñado para adaptarse elásticamente a sus fluctuaciones variantes, que presenta un comportamiento altamente tolerante a fallos y que se dirige por un procesamiento masivo de mensajes.
Pero más allá de todo esto, las arquitecturas reactivas se han convertido en un modelo de programación basado en transformaciones funcionales para dar soporte a sistemas dirigidos por eventos asíncronamente. En marco del desarrollo de soluciones para Front End, este tipo de aproximaciones está cogiendo tracción debido a lo bien que se adapta al modelo de interacción de la Web. En este contexto, los eventos responden a las interacciones del usuario sobre el agente navegador y la lógica de negocio se expresa como la transformación secuencial y progresiva de los mismos de forma encadenada. A lo largo de esta charla estudiaremos cómo funcionan este tipo de arquitecturas en contraposición con las clásicas soluciones MV* y presentaremos el modelo de desarrollo asociado.
Charla para JS Day Madrid 2015 09/05/2015:
- Video: https://goo.gl/jOm4aN
- Slideshare: http://goo.gl/cnTQw9
- Github: https://goo.gl/as8pdD
Cada lenguaje, cada tecnología, cada paradigma de programación persigue siempre la reutilización de código. En la comunidad de desarrollo se habla frecuentemente de DRY (Don’t Repeat Yourself) o WORE (Write Once Run Everywhere). Pero estos manidos mantras se quedan frecuentemente en una mera declaración de principios.
El código desarrollado para su reutilización no es capaz de reubicarse en otros contextos arquitectónicos de aquellos para los que fue inicialmente diseñado. Las capacidades de meta-programación de JavaScript le convierten en un lenguaje flexible y lo suficientemente plástico como para adaptarse dinámicamente a cualquier solución construida.
En esta charla exploramos como construir programas que se modifiquen a si mismos para resolver estos problemas y discutiremos mecanismos, técnicas y patrones de metaprogramación basados en componentes de software.
Video: http://goo.gl/acVK2t
Slideshare: http://goo.gl/2OChM4
Github: http://goo.gl/29ldtQ
La Web se está orientando a componentes. El objetivo es alcanzar una Web cada vez más madura, dirigida a fomentar la sencillez en las tareas de diseño y construcción, aumentar la rapidez y agilidad de desarrollo y mejorar la productividad general de las soluciones Web. Todo esto se consigue en parte debido al carácter declarativo que confiere la tecnología de componentes Web que, además, permite encapsular un comportamiento complejo, absorber la gestión adaptativa de los contenidos y, a la postre, generar un vocabulario propio de etiquetas de autor que fomenta la reutilización de código desde el front end.
Sin embargo, la comunidad demanda de manera creciente la definición de directrices y buenas prácticas en relación con las actividades de diseño y desarrollo vinculadas a la construcción de soluciones basadas en componentes Web. En esta charla ofreceremos una colección de principios que tienen por objetivo orientar a los equipos implicados en este tipo de proyectos.
La Web está evolucionando y los procesos de desarrollo en relación a la misma también lo hacen. Es una realidad vigente que cada vez más este tipo de soluciones pasarán por la construcción de componentes Web de negocio, etiquetas de autor que extienden el léxico del estándar HTML. Google vehicula esta solución a través del framework Polymer, cuya version 1.0 vio la luz hace pocos meses coincidiendo con la Google I/O 2015.
Pero en esta charla, no nos limitaremos a presentar las novedades de este Framework que pueden leerse directamente en la Web, que también. Hablaremos de los resultados de nuestra investigación en este terreno. Cuáles son los principios de diseño de componentes web, cuál es el modelo adecuado de componentes y cómo debe desarrollarse una arquitectura basada en componentes que cumpla con las necesidades arquetípicas de las soluciones Web y Mobil de hoy en día.
Arquitecturas de Componentes Web. Patrones de ComposiciónJavier Vélez Reyes
La tecnología de componentes web ha supuesto un revulsivo en la forma en la que se desarrollarán soluciones web en los próximos años. Si algo hemos aprendido, en este sentido, es que debemos dejar de construir aplicaciones monolíticas y empezar a pensar en crear componentes Web estratégicamente diseñados para que cubran las necesidades más comunes dentro de este tipo de problemas.
Polymer y los estándares de componentes Web nos proporcionan ya toda una panoplia de herramientas para construir este tipo de soluciones de manera más sencilla. Sin embargo, aun faltan muchos mimbres por establecer. La necesidad de un modelo arquitectónico de referencia se dibuja como una necesidad insoslayable para poder articular soluciones de éxito de esta naturaleza. En efecto una arquitectura nos ofrece un marco prescriptivo preciso donde dar forma a las contribuciones de múltiples partes para crear un catálogo de componentes coherente que pueda ser utilizado por la comunidad para construir soluciones orientadas a componentes web.
En relación a lo anterior, a lo largo de esta charla centraremos nuestra atención en un problema nuclear: ¿Cómo deben articularse los procesos de composición en el marco de esta tecnología? Para responder esta pregunta no debemos olvidar que este nuevo paradigma prescribe un proceso constructivo desarrollado en el ámbito declarativo del lenguaje HTML y no en el espacio programático de JavaScript, dado que así se consiguen procesos de desarrollo más sencillos, ágiles y productivos. En relación a la composición todo esto implica que no sólo debemos esforzarnos por crear componentes visuales que den respuesta a las necesidades recurrentes de interacción en el plano del front sino que, adicionalmente, debemos elaborar un conjunto de componentes dedicado a a estereotipar y encapsular toda aquella lógica de composición más común. De esta manera el desarrollo de soluciones orientadas a componentes web alcanzará su madurez plena al convertir un tedioso proceso constructivo en un ejercicio de confección compositiva asistido por componentes que proporcionan código pegamento. Todo esto se resume en que debemos crear componentes visuales, sí, pero además componentes para componer.
Tradicionalmente, los modelos de componentes utilizados en el mundo de front se utilizan como un mecanismo de modularidad para descomponer una solución. De forma más ambiciosa, se construyen sistemas de diseño basados en componentes en aras a aumentar la reutilización entre proyectos y mejorar la productividad en los desarrollos.
Sin embargo, para que la reutilización se convierta en una realidad constatable necesitamos cambiar nuestra aproximación al problema. Más que crear arquitecturas polimórficas que acepten distintos tipos de componentes. Necesitamos crear componentes que sean capaces de adaptarse plásticamente y de forma dinámica a cada contexto arquitectónico de uso.
En esta charla presentaremos una colección de técnicas y modelos de adaptación que pueden ser aplicados sobre nuestros sistemas de componentes con independencia del stack tecnológico en que estén implementados: Vue, React, Polymer, etc. Si perteneces al mundo del front y te gusta ver código esta charla te interesará.
La Web está cambiado. Es una realidad. En poco más de 20 años, esta plataforma ha evolucionado sus pragmáticas de uso impactando también el modelo cultural de nuestra sociedad. Primero fue un espacio virtual de recursos estáticos. Hoy un gran entramado de relaciones sociales donde se confunde lo virtual y lo real. ¿Internet es un reflejo de lo que somos o más bien nos hemos adaptado a como es Internet hoy en día por diseño?
Pero un nuevo cambio se vislumbra en el futuro inmediato. La Web no será una herramienta más a nuestro alcance para disfrute discrecional. Empezamos a vivir en una burbuja digital donde la Web llega a nosotros y nosotros la gestionamos de forma micro-interactiva y reactiva.
La pregunta que debemos hacernos en este nuevo escenario es, ¿Que papel jugamos como desarrolladores, diseñadores, especialista UX y personal técnico en esta nueva Web? ¿Cual es mi espacio de acción y mi responsabilidad? En esta charlase ofrece un decálogo de cambios para los que debemos prepararnos que ayudarán a responder a esta pregunta.
Esta charla es la Key Note del Keep Coding Connect 2017. Un evento para desarrolladores organizadas por una de las compañías referentes en formación técnica en este país.
Arquitectura de Componentes Web. Patrones de Acceso a DatosJavier Vélez Reyes
La mayor parte de los aplicativos que manejamos hoy en día corresponden con arquitecturas centradas en los datos. Modelos de información expuestos en forma de servicios que son explorados en profundidad. En este contexto, las arquitecturas de componentes Web se presentan como una solución idónea para llevar a cabo este proceso exploratorio de manera sencilla y declarativa. A lo largo de esta charla discutiremos este tipo de arquitecturas y presentaremos los patrones de diseño fundamentales que resuelven este tipo de escenarios.
El mundo cambia. Los nuevos medios de interacción basados en texto e imagen, las interfaces orales y de realidad aumentada e inmersiva dibuja una nueva forma en la que los usuarios se acercan a los negocios. Como ingenieros debemos orientar a los clientes en este cambio. Nuestra labor como arquitectos es prepararnos tecnológicamente. En esta charla discutimos cómo podemos enfrentar este cambio y cómo debemos reorientar el diseño de nuestras arquitecturas para hacer frente a este nuevo paradigma de uso. Si quieres aprender a hacer el software del futuro esta es la charla que no te debes perder
En los últimos años se ha hablado mucho de los estilos arquitectónicos en boga para desarrollar las soluciones orientadas a servicios. Sin embargo, cuando diseñamos servicios caemos siempre en los mismos esquemas y los repetimos de proyecto a proyecto sin ponernos en cuestión su validez para cada problema en cuestión.
En esta charla haremos un recorrido de los fundamentales modelos de diseño de APIs de servicios que pueden desarrollarse para cada tipo de problema. Además ofreceremos técnicas y patrones de diseño aplicables para cada uno de estos modelos.
NodeJS es una plataforma que permite programar servidores dedicados en Javascript de forma sencilla y eficaz. Pese a que Javascript no es un lenguaje con soporte a la concurrencia, el carácter no bloqueante de las operaciones que realizan accesos de entrada salida E/S permite avanzar los flujos de ejecución aumentando la productividad y la escalabilidad del sistema total. En efecto, los tiempos de espera en cada operación motivados por los accesos a disco son aprovechados para procesar nuevas peticiones entrantes en el servidor. Pese a sus innegables ventajas en productividad, el modelo de programación se complica. Dado que ahora las operaciones se liberan del flujo de control para retomarse posteriormente, ¿cómo podemos determinar cuándo una operación ha terminado? ¿Cómo podemos recuperar sus resultados? ¿Cómo gestionamos sus errores potenciales? A lo largo de este texto presentaremos diferentes modelos de programación que pueden ser empleado para dar respuesta a estas y otras preguntas en el marco de la programación asíncrona.
Programación Funcional en Javascript. 27/10/2014. NodeJS Madrid
Video: http://bit.ly/1xTizFc
Code: http://bit.ly/1qmmR3Q
La programación funcional está cogiendo fuerte tracción en los últimos años dentro de la comunidad de desarrollo. Tal vez ello se deba al surgimiento de nuevas arquitecturas que demandan cotas de escalabilidad, resistencia y flexibilidad en el marco de soluciones centradas en procesos de transformación. Pero más allá de una simple moda, como trataremos de mostrar en esta charla, la programación funcional conduce a soluciones de código robustas, versátiles y expresivas que difícilmente son comparables con las propias de la orientación a objetos.
Además JavaScript, como la mayoría de los lenguajes de scripting es un lenguaje idiomático que invita a pensar en términos funcionales. De hecho muchas veces, cuando programamos en Javascript, desarrollamos soluciones funcionales casi sin darnos cuenta. Pero para trabajar correctamente en el marco de este paradigma debemos saber, qué es exactamente la programación funcional, cuáles son sus ventajas y principios fundacionales, de qué mecanismos se sirve, qué técnicas de programación se utilizan, qué patrones de diseño funcional existen a nuestra disposición y qué estilos arquitectónicos emergen.
En esta charla descubriremos cómo se construyen arquitecturas funcionales dirigidas por los datos, hablaremos de programación por capas basada en orden superior y presentaremos modelos de programación concomitantes como la programación reactiva basada en streams o las arquitecturas map/reduce propias de las técnicas de big data.
Oracle SOA Suite es una plataforma de software completa que permite implementar y administrar una arquitectura orientada a servicios ofreciendo flexibilidad y robustez.
Aprenda como Oracle SOA Suite permite diseñar procesos de negocio que integren transversalmente los sistemas de la organización, mejorando la capacidad de esta para conocer en tiempo real el estado del negocio, y por tanto, permitiendo responder de forma proactiva a las necesidades detectadas de una forma rápida y efectiva.
Descubra en este webinar las ventajas que le aportará el diseño y definición de una hoja de ruta SOA durante la implantación de una arquitectura orientada a servicios. El diseño de la hoja de ruta está basado en el análisis de indicadores que muestran el nivel de madurez dentro del Modelo de Referencia de Madurez SOA.
Tradicionalmente, los modelos de componentes utilizados en el mundo de front se utilizan como un mecanismo de modularidad para descomponer una solución. De forma más ambiciosa, se construyen sistemas de diseño basados en componentes en aras a aumentar la reutilización entre proyectos y mejorar la productividad en los desarrollos.
Sin embargo, para que la reutilización se convierta en una realidad constatable necesitamos cambiar nuestra aproximación al problema. Más que crear arquitecturas polimórficas que acepten distintos tipos de componentes. Necesitamos crear componentes que sean capaces de adaptarse plásticamente y de forma dinámica a cada contexto arquitectónico de uso.
En esta charla presentaremos una colección de técnicas y modelos de adaptación que pueden ser aplicados sobre nuestros sistemas de componentes con independencia del stack tecnológico en que estén implementados: Vue, React, Polymer, etc. Si perteneces al mundo del front y te gusta ver código esta charla te interesará.
La Web está cambiado. Es una realidad. En poco más de 20 años, esta plataforma ha evolucionado sus pragmáticas de uso impactando también el modelo cultural de nuestra sociedad. Primero fue un espacio virtual de recursos estáticos. Hoy un gran entramado de relaciones sociales donde se confunde lo virtual y lo real. ¿Internet es un reflejo de lo que somos o más bien nos hemos adaptado a como es Internet hoy en día por diseño?
Pero un nuevo cambio se vislumbra en el futuro inmediato. La Web no será una herramienta más a nuestro alcance para disfrute discrecional. Empezamos a vivir en una burbuja digital donde la Web llega a nosotros y nosotros la gestionamos de forma micro-interactiva y reactiva.
La pregunta que debemos hacernos en este nuevo escenario es, ¿Que papel jugamos como desarrolladores, diseñadores, especialista UX y personal técnico en esta nueva Web? ¿Cual es mi espacio de acción y mi responsabilidad? En esta charlase ofrece un decálogo de cambios para los que debemos prepararnos que ayudarán a responder a esta pregunta.
Esta charla es la Key Note del Keep Coding Connect 2017. Un evento para desarrolladores organizadas por una de las compañías referentes en formación técnica en este país.
Arquitectura de Componentes Web. Patrones de Acceso a DatosJavier Vélez Reyes
La mayor parte de los aplicativos que manejamos hoy en día corresponden con arquitecturas centradas en los datos. Modelos de información expuestos en forma de servicios que son explorados en profundidad. En este contexto, las arquitecturas de componentes Web se presentan como una solución idónea para llevar a cabo este proceso exploratorio de manera sencilla y declarativa. A lo largo de esta charla discutiremos este tipo de arquitecturas y presentaremos los patrones de diseño fundamentales que resuelven este tipo de escenarios.
El mundo cambia. Los nuevos medios de interacción basados en texto e imagen, las interfaces orales y de realidad aumentada e inmersiva dibuja una nueva forma en la que los usuarios se acercan a los negocios. Como ingenieros debemos orientar a los clientes en este cambio. Nuestra labor como arquitectos es prepararnos tecnológicamente. En esta charla discutimos cómo podemos enfrentar este cambio y cómo debemos reorientar el diseño de nuestras arquitecturas para hacer frente a este nuevo paradigma de uso. Si quieres aprender a hacer el software del futuro esta es la charla que no te debes perder
En los últimos años se ha hablado mucho de los estilos arquitectónicos en boga para desarrollar las soluciones orientadas a servicios. Sin embargo, cuando diseñamos servicios caemos siempre en los mismos esquemas y los repetimos de proyecto a proyecto sin ponernos en cuestión su validez para cada problema en cuestión.
En esta charla haremos un recorrido de los fundamentales modelos de diseño de APIs de servicios que pueden desarrollarse para cada tipo de problema. Además ofreceremos técnicas y patrones de diseño aplicables para cada uno de estos modelos.
NodeJS es una plataforma que permite programar servidores dedicados en Javascript de forma sencilla y eficaz. Pese a que Javascript no es un lenguaje con soporte a la concurrencia, el carácter no bloqueante de las operaciones que realizan accesos de entrada salida E/S permite avanzar los flujos de ejecución aumentando la productividad y la escalabilidad del sistema total. En efecto, los tiempos de espera en cada operación motivados por los accesos a disco son aprovechados para procesar nuevas peticiones entrantes en el servidor. Pese a sus innegables ventajas en productividad, el modelo de programación se complica. Dado que ahora las operaciones se liberan del flujo de control para retomarse posteriormente, ¿cómo podemos determinar cuándo una operación ha terminado? ¿Cómo podemos recuperar sus resultados? ¿Cómo gestionamos sus errores potenciales? A lo largo de este texto presentaremos diferentes modelos de programación que pueden ser empleado para dar respuesta a estas y otras preguntas en el marco de la programación asíncrona.
Programación Funcional en Javascript. 27/10/2014. NodeJS Madrid
Video: http://bit.ly/1xTizFc
Code: http://bit.ly/1qmmR3Q
La programación funcional está cogiendo fuerte tracción en los últimos años dentro de la comunidad de desarrollo. Tal vez ello se deba al surgimiento de nuevas arquitecturas que demandan cotas de escalabilidad, resistencia y flexibilidad en el marco de soluciones centradas en procesos de transformación. Pero más allá de una simple moda, como trataremos de mostrar en esta charla, la programación funcional conduce a soluciones de código robustas, versátiles y expresivas que difícilmente son comparables con las propias de la orientación a objetos.
Además JavaScript, como la mayoría de los lenguajes de scripting es un lenguaje idiomático que invita a pensar en términos funcionales. De hecho muchas veces, cuando programamos en Javascript, desarrollamos soluciones funcionales casi sin darnos cuenta. Pero para trabajar correctamente en el marco de este paradigma debemos saber, qué es exactamente la programación funcional, cuáles son sus ventajas y principios fundacionales, de qué mecanismos se sirve, qué técnicas de programación se utilizan, qué patrones de diseño funcional existen a nuestra disposición y qué estilos arquitectónicos emergen.
En esta charla descubriremos cómo se construyen arquitecturas funcionales dirigidas por los datos, hablaremos de programación por capas basada en orden superior y presentaremos modelos de programación concomitantes como la programación reactiva basada en streams o las arquitecturas map/reduce propias de las técnicas de big data.
Oracle SOA Suite es una plataforma de software completa que permite implementar y administrar una arquitectura orientada a servicios ofreciendo flexibilidad y robustez.
Aprenda como Oracle SOA Suite permite diseñar procesos de negocio que integren transversalmente los sistemas de la organización, mejorando la capacidad de esta para conocer en tiempo real el estado del negocio, y por tanto, permitiendo responder de forma proactiva a las necesidades detectadas de una forma rápida y efectiva.
Descubra en este webinar las ventajas que le aportará el diseño y definición de una hoja de ruta SOA durante la implantación de una arquitectura orientada a servicios. El diseño de la hoja de ruta está basado en el análisis de indicadores que muestran el nivel de madurez dentro del Modelo de Referencia de Madurez SOA.
Se muestra una introducción a Web Services, un caso de la vida real, se propone un ejercicio y finalmente se muestra un ejemplo del tipo "hola mundo" y se explica como se realiza
Presentación utilizada en el Java Day Santiago RD. Un esfuerzo de la comunidad Java Dominicano y el Comité de Estudiantes de Ingeniería de Sistemas y Computación (CISC) & Departamento de Ingeniería de Sistemas y Computación de la PUCMM.
Celebrado en fecha 28 de Marzo de 2015. Santiago De Los Caballeros, Dominican Republic
Se presentó como trabajo de investigación de la asignatura Programación Web de la carrera Ingeniería en Sistemas de la Universidad de Cuenca, realizar un documento en el cual se detallen las métricas y demás aspectos necesarios para poder elaborar un trade-off sobre las diferentes tecnologías web en la actualidad.
¿Qué es la Web Semántica? En esta presentación podrás conocer más acerca de ella, su lenguaje, aplicaciones y cómo hacer para construir una web más inteligente.
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
En esta charla, nos sumergiremos en los desafíos emergentes que la inteligencia artificial (IA) y los Large Language Models (LLMs) traen al mundo de la calidad del software y el testing. Exploraremos cómo la integración, uso o diseño de modelos de IA plantean nuevos retos, incluyendo la calidad de datos y detección de sesgos, sumando la complejidad de probar algo no determinístico. Revisaremos algunas propuestas que se están llevando adelante para ajustar nuestras tareas de testing al desarrollo de este tipo de sistemas, incluyendo enfoques de pruebas automatizadas y observabilidad.
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
2. @javiervelezreye 2
Presentación
Componentes Web y El Framework Polymer
Licenciado en informá2ca por la Universidad Politécnica de
Madrid (UPM) desde el año 2001 y doctor en informá2ca por la
Universidad Nacional de Educación a Distancia (UNED) desde el
año 2009, Javier es inves2gador y está especializado en el diseño
y análisis de la colaboración. Esta labor la compagina con
ac2vidades de evangelización, consultoría, mentoring y formación
especializada para empresas dentro del sector IT. Inquieto, ávido
lector y seguidor cercano de las innovaciones en tecnología.
I. ¿Quién Soy?
II. ¿A Qué Me Dedico?
Desarrollado Front/Back
Evangelización Web
Arquitectura SoVware
Formación & Consultoría IT
E-learning
Diseño de Sistemas de Colaboración
Learning Analy2cs
Gamificación Colabora2va
javier.velez.reyes@gmail.com
@javiervelezreye
linkedin.com/in/javiervelezreyes
gplus.to/javiervelezreyes
jvelez77
javiervelezreyes
youtube.com/user/javiervelezreyes
13. @javiervelezreye 13
Conceptos Esenciales
Componentes Web y El Framework Polymer
I. Introducción
El modelo de componentes para la Web definido por la W3C consiste en cuatro
especificaciones tecnológicamente independientes que cubren dis2ntos aspectos del proceso
construc2vo. A lo largo de este capítulo revisaremos los conceptos esenciales que se manejan
en relación a tales especificaciones
Shadow DOM
Ofrece un modelo de encapsulamiento
que permite aislar el contenido interno
del componente de aquél en la página
donde éste es renderizado
Templates
Ofrece un modelo de construcción
basado en planEllas inertes de código
HTML que sólo son acEvadas cuando
se renderiza el componente
HTML Imports
Ofrece un modelo de modularización
basado en la posibilidad de incluir
ficheros de código HTML dentro de
otros ficheros HTML
Custom Elements
Ofrece un modelo de extensibilidad
que permite a los desarrolladores
definir sus propias eEquetas o redefinir
semánEcamente las eEquetas del
estándar DOM
17. @javiervelezreye 17
Conceptos Esenciales
Componentes Web y El Framework Polymer
II. Modelo de Encapsulamiento. Shadow DOM
var host = this;
host.querySelector(‘.foo’);
...
JS
El componente es una eEqueta accesible desde
el DOM. Para navegar el light DOM se usan los
mecanismos convencionales
A. Acceso a Light DOM
Shadow DOM Light DOM
this
.shadowRoot
var root = this.shadowRoot;
root.querySelector(‘.foo’);
...
JS
El componente es una eEqueta accesible desde
el DOM. Para acceder al root se navega por la
propiedad shadowRoot
B. Acceso a Shadow DOM
Shadow DOM Light DOM
this
.shadowRoot
En resumen, el modelo de encapsulación no oculta nada truculento. Cada nodo host dispone
de un enlace a un árbol DOM paralelo que puede ser recorrido de forma habitual siempre que
se recuerde que su punto de acceso es el shadow root.
Shadow Host, Shadow Root & Shadow DOM Shadow.1.html
20. @javiervelezreye 20
Conceptos Esenciales
Componentes Web y El Framework Polymer
II. Modelo de Encapsulamiento. Shadow DOM
var ip = root.querySelector(‘#i’);
var dNodes = ip.getDistributedNodes ();
dNodes...
JS
Seleccionado un punto de inserción se pueden
localizar los nodos del Light DOM que son
distribuidos en el shadow DOM
A. Acceso a Nodos Distribuidos
var e = host.querySelector (‘#i’);
var ips = e.getDestinationInsertionPoints();
ips...
JS
Para saber los puntos de inserción desde donde
un determinado nodo del Light DOM es referido
se accede a los puntos de inserción de desEno
B. Acceso a Puntos de Inserción de DesSno
Shadow DOM Light DOM
this
.shadowRoot
<div id=‘i’>
Es posible consultar programá2camente la colección de nodos del light DOM que son referidos
desde un punto de inserción así como saber en qué puntos de inserción se distribuye un
determinado nodo del light DOM.
Puntos de Inserción & EYqueta Content
Shadow DOM Light DOM
this
.shadowRoot
<content id=‘i’>
Shadow.2.html
28. @javiervelezreye 28
Conceptos Esenciales
Componentes Web y El Framework Polymer
IV. Modelo de Extensión. Custom Elements
Ahora que tenemos los mecanismos necesarios para definir y encapsular comportamiento y
lógica de presentación personalizada necesitamos una manera de referirlo nominalmente
dentro de nuestra página Web en forma de e2quetas personalizadas. Esto permite dis2nguir
los componentes de las e2quetas estándar lo que aumenta la legibilidad de la página.
Creación de EYquetas Personalizadas. Custom Tags
Página Huésped
...
<wc-calendar>
<wc-calendar-day>12</wc-calendar-day>
<wc-calendar-month>06</wc-calendar-month>
<wc-calendar-year>2014</wc-calendar-year>
</wc-calendar>
...
Las eEquetas personalizadas son un Epo de
elementos personalizados que permite uElizar una
referencia nominal para instanciar un componente
ya construido dentro de una página. No obstante
existen dos reglas de nombrado
ESquetas Personalizadas
Los nombres de las eEquetas personalizadas
deben tener al menos un guión en el nodeName
para diferenciarlas de las eEquetas estándar.
Regla 1. Nombres con al menos un guión
<wc-calendar> ... </wc-calendar>
No pueden uElizarse como nombres de eEquetas
personalizadas cualquiera de las cadenas con
guión que se enumeran a conEnuación.
Regla 2. Nombres reservados
annotation-xml color-profile font-face
font-face-src font-face-uri font-face-format
font-face-name missing-glyph
29. @javiervelezreye 29
Conceptos Esenciales
Componentes Web y El Framework Polymer
IV. Modelo de Extensión. Custom Elements
Debemos preocuparnos, por un lado, de registrar cada componente construido como un nuevo
2po de e2queta dentro del sistema de e2quetas del navegador y después de instanciar
componentes tanto desde el lenguaje de marcado como a través de JS.
Creación de EYquetas Personalizadas. Custom Tags
Registro de un Componente
<polymer-element name=“wc-foo”>
<template>...</template>
<script>
Polymer (‘wc-foo’, {
// prototipo del componente (foo, bar...)
});
</script>
</polymer-element>
HTML/JS
var p = Object.create(HTMLElement.prototype);
p.foo = function (){...};
p.bar = 7;
var Foo = document.registerElement(
‘wc-foo’,
{prototype: p});
JS
Tanto los snippets de código de registro
como de instanciación son versiones
equivalentes y mutuamente excluyentes
Instanciación de un Componente
<wc-foo id=“a”>
...
</wc-foo>
<wc-foo id=“b”>
...
</wc-foo>
HTML
var a = new Foo ();
var b = document.createElement(‘wc-foo’);
document.body.appendChild (a);
document.body.appendChild (b);
JS
Custom.html
30. @javiervelezreye 30
Conceptos Esenciales
Componentes Web y El Framework Polymer
IV. Modelo de Extensión. Custom Elements
Por otro lado, resulta de interés extender las propias e2quetas del estándar HTML para
generar variantes que incluyan nuevo comportamiento o lógica presentacional cuando se
rendericen. Estas e2quetas man2enen, naturalmente, el nombre de la e2queta a la que
ex2enden pero incluyen un calificador is para indicar al navegador de que se trata de una
variante dis2nta
Extensión de EYquetas Estándar. Extended Element Types
Página Huésped
...
<button id=“btn” is=“fancy-button”>
Ok
</button>
<p is=“lorem-ipsum”><p>
...
<script>
var btn = document.querySelector(‘#btn’);
btn.addEventListener(‘click’, function(e){
...
});
</script>
Las eEquetas del estándar se exEenden con
variantes cualificadas nominalmente dentro del
atributo is. Estas eEquetas manEenen el nombre,
métodos y atributos de la eEqueta de la que
derivan pero pueden sobrescribir o agregar nuevas
capacidades
Extensión de ESquetas Estándar
La nueva variante de botón incluye, por herencia
todos los atributos, métodos y modelo de eventos
que Eene la eEqueta base de la que deriva
Herencia de Capacidades
31. @javiervelezreye 31
Conceptos Esenciales
Componentes Web y El Framework Polymer
IV. Modelo de Extensión. Custom Elements
De forma similar al caso anterior, comenzaremos por registrar cada componente construido
como una variante que ex2ende una e2queta del estándar y después nos ocuparemos de
instanciar componentes tanto desde el lenguaje de marcado como a través de JS.
Extensión de EYquetas Estándar. Extended Element Types
Extensión de una ESqueta
<polymer-element name=“fancy-button”
extends=“button”>
<template>...</template>
<script>
Polymer (‘fancy-button’, {
// prototipo de la etiqueta (foo, bar...)
});
</script>
</polymer-element>
HTML/JS
var p = Object.create(HTMLButtonElement.prototype);
p.foo = function (){...};
p.bar = 7;
Var FancyButton = document.registerElement(
‘fancy-button’,
{extends: ‘button’,
prototype: p});
JS
Tanto los snippets de código de registro
como de instanciación son versiones
equivalentes y mutuamente excluyentes
Instanciación de una ESqueta
<button is=“fancy-button”
id=“a”> Ok </button>
<button is=“fancy-button”
id=“b”> Ok </button>
HTML
var a = new FancyButton ();
Var b = document.createElement
(‘fancy-button’);
document.body.appendChild (a);
document.body.appendChild (b);
JS
32. @javiervelezreye 32
Conceptos Esenciales
Componentes Web y El Framework Polymer
IV. Modelo de Extensión. Custom Elements
Es importante recalcar que los Componentes Web, una vez establecidos como elementos
personalizados atraviesan dis2ntas fases a lo largo del proceso de construcción, inserción y
potencial borrado del árbol DOM de la página huésped. El estándar ofrece método
manejadores que permiten la interposición de código en respuesta a cada una de las fases que
caracterizan dicho ciclo de vida. A con2nuación describimos someramente las mismas.
CREATED READY ATTACHED
DOM_READY DETACHED ATRIBUTE_CHANGED
El componente se ha creado y ha
sido registrado con éxito como
una nueva eEqueta o extensión
El componente está preparado.
Shadow DOM creado. Observa-
dores establecidos. Manejadores
de eventos vinculados
Una nueva instancia de algún
componente creado se ha inser-
tado dentro de la página hués-
ped
Se garanEza que todos los
componentes anidados dentro
de éste están preparados
La instancia del componente se
ha eliminado de la página
huésped
Un atributo de la instancia del
componente fue añadido,
borrado o actualizado
registro
componente
Ok
Ok
X
!
33. @javiervelezreye 33
Conceptos Esenciales
Componentes Web y El Framework Polymer
V. Modelo de Modularización. HTML Imports
Página Huésped
<!doctype html>
<html lang=“es”>
<head>
<meta charset=“utf-8”>
<script src=“platform.js”></script>
<script src=“polymer.js”></script>
<link rel=“import” href=“wc-foo.html”>
</head>
<body>
<wc-foo></wc-foo>
</body>
</html>
wc-foo.html
<polymer-element name=“wc-foo”>
<template>...</template>
<script>
Polymer (‘wc-foo’, {
// prototipo del componente
});
</script>
</polymer>
La URL asociada a un import se llama import
locaEon. Para acceder a un documento hospedado
en otro dominio deben habilitarse los permisos
CORS.
Import LocaSon
Según lo expuesto, la implementación de un componente incluye un código de plan2lla inerte,
especificaciones de es2lo y no poca lógica de scrip2ng para especificar el modelo de
comportamiento del mismo. Parece necesario disponer de un mecanismo de modularización
que permita incluir todo ese contenido en un fichero de índice a parte HTML que pueda
importarte a la página huésped.
Importación de documentos HTML
34. @javiervelezreye 34
Conceptos Esenciales
Componentes Web y El Framework Polymer
V. Modelo de Modularización. HTML Imports
Página Huésped
<!doctype html>
<html lang=“es”>
<head>
<meta charset=“utf-8”>
<script src=“platform.js”></script>
<script src=“polymer.js”></script>
<link rel="import" href=“my-lib.html”>
</head>
<body>
...
</body>
</html>
my-lib.html
<!doctype html>
<html lang=“es”>
<head>
<link rel=“import” href=“tag-1.html”>
<link rel=“import” href=“tag-2.html”>
<link rel=“stylesheet” href=“style-1.html”>
<link rel="stylesheet" href=“style-2.html”>
<script src=“script-1.js”></script>
<script src=“script-2.js”></script>
</head>
<body>
<polymer-element>
...
</polymer-element>
</body>
</html>
Los mecanismos de modularización proporcionados por la direc2va import ofrecen
oportunidades para el empaquetamiento de colecciones de recursos y manera que éstos
puedan ser entregados al cliente final a través de una única import loca2on.
Empaquetamiento de Recursos
style-2.css
style-1.css
script-2.js
script-1.js
tag-2.html
tag-1.html
A través de la carga indirecta de un fichero de
índice se cargan en la página huésped todos los
recursos a los que éste apunta o conEene
Carga Indirecta
Import.html
35. @javiervelezreye 35
Conceptos Esenciales
Componentes Web y El Framework Polymer
V. Modelo de Modularización. HTML Imports
Para controlar programá2camente desde JavaScript los procesos de carga de recursos de
documentos HTML importados mediante la clausula import la plataforma proporciona sendos
eventos sobre los que se pueden inyectar manejadores.
Eventos de Carga y Error
Enlace a Texto
<script async>
function handleLoad(e) {
console.log(‘Loaded import:’ + e.target.href);
}
function handleError(e) {
console.log(‘Error loading import:’ + e.target.href);
}
</script>
<link rel=“import” href=“file.html”
onload=“handleLoad(event)” onerror=“handleError(event)”>
Enlace a Atributo
HTML/JS
El elemento link lanza un evento load cuando
un recurso HTML ha terminado su proceso de
carga de forma exitosa.
Si se produce algún error durante el proceso
de carga del recurso HTML, por ejemplo error
404, recurso no encontrado, la eEqueta link
lanzará un evento error
36. @javiervelezreye 36
Conceptos Esenciales
Componentes Web y El Framework Polymer
V. Modelo de Modularización. HTML Imports
Importar un recurso HTML mediante la cláusula import no supone un volcado tal cual del
contenido sino que requiere de un procesamiento del mismo. Esto implica que es
desarrollador 2ene la oportunidad de capturar programá2camente dicho el contenido y operar
sobre él a conveniencia.
Manipulación del Contenido de los Recursos Importados
<head>
<link id=“foo-link” rel=“import” href=“wc-foo.html”>
</head>
<body>
...
<script>
var link = document.querySelector(‘#foo-link’);
var content = link.import;
var el = content.querySelector(‘...’);
...
</script>
</body>
HTML/JS
37. @javiervelezreye 37
Conceptos Esenciales
Componentes Web y El Framework Polymer
V. Modelo de Modularización. HTML Imports
Debemos ser conscientes de que los ficheros importados, en tanto que son documentos HTML,
pueden incluir fragmentos de scrip2ng. Dentro de estos scripts es posible referir tanto al
documento HTML que los con2ene como al documento HTML donde son hospedados a través
de la direc2va de importación.
Acceso al Recurso Importado y a la Página Huésped
Página Huésped
<!doctype html>
<html lang=“es”>
<head>
<meta charset=“utf-8”>
<script src=“platform.js”></script>
<script src=“polymer.js”></script>
<link rel="import" href=“file.html”>
</head>
<body>
...
</body>
</html>
file.html
<!doctype html>
<html lang=“es”>
<head>
...
</head>
<body>
<script>
var f = document.currentScript.ownerDocument;
var h = document;
// f refiere a este documento HTML
// h refiere a la página huésped
</script>
</body>
</html>
Regla de importación 1.
El contexto en el que se evalúan los
script dentro de una página
importada es el de la página huésped
Regla de importación 2.
Las importaciones son no bloqueantes.
Sin embargo los script dentro de la
página importada se ejecutan en orden
Regla de importación 3.
Las importaciones desde una misma
URL son procesadas solo una vez con lo
que sus script sólo se ejecutan una vez
41. @javiervelezreye 41
Aplicaciones Web Basadas en Componentes
Componentes Web y El Framework Polymer
II. Modelos de Localización entre Componentes Web
Localización Explícita
Cada componente recibe una referencia
explícita nominal de los componentes con los
que Eene que establecer un ejercicio de
coordinación
Localización Implícita
Cada componente es responsable de localizar
(por rol) dentro del entorno a los demás
componentes con los que Eene que establecer
un ejercicio de coordinación
A
B
Inyección
explícita
C
A
E
D
B
A
Localización
por búsqueda
de roles
El modelo de localización está relacionado con la selección de los mecanismos adecuados para
el establecimiento efec2vo de conexiones semán2cas o funcionales entre componentes que
deben mantenerse en coordinación para ofrecer un servicio de valor añadido al contexto
donde habitan.
43. @javiervelezreye 43
Aplicaciones Web Basadas en Componentes
Componentes Web y El Framework Polymer
IV. Modelos Coordinación de Componentes Web
Coordinación Coreográfica
La coordinación coreográfica responde a
esquemas de parEcipación distribuida donde
cada componente es responsable de reaccionar
de manera autónoma de acuerdo a un consenso
preestablecido
Coordinación Orquestal
En los mecanismos por orquestación la lógica de
coordinación es ejecutada por un componente
central que dispone de un script que detalla el
proceso coordinaEvo que es necesario efectuar
entre los componentes parEcipantes
A
Coordinación
distribuida
C B
O A
B
C
Coordinación
centralizada
Asimismo, necesitamos establecer los mecanismos de coordinación que serán aplicados entre
los componentes implicados en aras a ofrecer servicios de valor añadido. En términos
generales, es posible establecer dos grandes familias de esquemas coordina2vos, los
coreográficos y los de orquestación en función de su carácter distribuido o centralizado.