1 DESK 3.0 Tratamiento Automático, mediante DESK, de aspectos dinámicos relativos a la renderización de la información en PEGASUS José A. Macías y Pablo Castells

2 Dos Casos a Estudiar 1) Cambios Simples sobre la generación dinámica de HTML a través de código JAVA –Tratamiento de expresiones JSP: –Ejecución de métodos sobre Objetos del Dominio: 2) Manipulación y Tratamiento de Reglas de Presentación mediante DESK

3 Cambios simples sobre la generación dinámica de HTML a través de código JAVA

4 Permiten cambiar aspectos dinámicos sobre la presentación –Aspectos que no pueden ser tratados directamente a partir de la información estática disponible en el sistema Modelo del Dominio Plantilla del Modelo de la Presentación Vinculados a la generación automática de código HTML mediante el lenguaje JAVA. Objetos del Dominio presentes en la Plantilla JSP del Modelo de la Presentación

5 Estado “inicial” de la presentación –Estado por defecto, se ejecutará y se guardará antes de que cualquier regla cambie el “estado” de la presentación (Ejemplo: prerequisites.tree() ) –Generado por HADES. Módulo de creación de los modelos por defecto (Modelo de la Presentación) Se creará un protocolo, a partir de métodos, para alterar el estado de la visualización –Métodos bien definidos, construidos homogéneamente. –La “renderización” podrá alterarse a partir del paso de mensajes entre objetos del dominio prerequisites.tree(“Horizontal”) prerequisites.tree(“Vertical”) Cambios simples sobre la generación dinámica de HTML a través de código JAVA

6 Dos Ejemplos de uso –Ejemplo de Uso 1 Modificación de la visualización de una lista de elementos (cambio de disposición de los elementos) –Ejemplo de Uso 2 Introducción de una condición sobre la visualización de ciertos elementos de la presentación bajo el Modelo del Usuario (Adaptación al Usuario)

7 Ejemplo de Uso 1 1) El usuario, bajo DESK, selecciona el texto de una lista para cambiar la disposición de los elementos, de vertical a horizontal 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End)

8 Ejemplo de Uso 1 (II) Modelo de la Presentación Original 4) DESK modifica directamente el modelo de la Presentación, mediante el uso del protocolo de paso de mensajes entre objetos del dominio Modelo de la Presentación Modificado.........

9 Ejemplo de Uso 1 (y III) ProblemasProblemas –No está clara la localización del contexto “prerequisites” a partir de una serie de “items” seleccionados bajo DESK (ver posible solución a este problema más adelante) Posibilidades / AmpliacionesPosibilidades / Ampliaciones –Tener en cuenta el hecho de que el usuario pueda ir realizando los cambios de conversión (Vertical=>Horizontal (Tabla)) poco a poco, convirtiendo los “items” de uno en uno, además de tener la posibilidad de utilizar una primitiva de conversión automática (mediante un botón en DESK) Análisis del Modelo de Monitorización sobre la Lista ID=LIST21 –Posibilidad de realizar un “Filtrado de Ruido” del Modelo de Monitorización, eliminando sentencias redundantes (por ejemplo quitar y poner negrita en pasos sucesivos), además de tratar casos como los descritos en el punto anterior Módulo de Filtrado o Post-Procesamiento del Modelo de Monitorización

10 Ejemplo de Uso 2 1) El usuario, bajo DESK, selecciona un texto que se desea visualizar solamente si el usuario es mayor de edad 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End) =18... 3) DESK Localiza el Contexto (Back-End) ....", "width": "800" } 12 Ejemplo de Uso 2 (y III) ProblemaProblema –¿Qué sucede si el texto seleccionado bajo DESK ya estaba bajo una condición sobre el Modelo de Usuario? Posible SoluciónPosible Solución –Que PEGASUS inserte meta-información codificada dentro de las etiquetas HTML generadas, de esta forma se podría localizar, bajo DESK, información administrativa relativa al texto sujeto a una condición texto Pre-Procesador de plantillas JSP para la generación de meta- información embebida en el HTML generado { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_12.jpg", "name": "Ejemplo de Uso 2 (y III) ProblemaProblema –¿Qué sucede si el texto seleccionado bajo DESK ya estaba bajo una condición sobre el Modelo de Usuario.", "description": "Posible SoluciónPosible Solución –Que PEGASUS inserte meta-información codificada dentro de las etiquetas HTML generadas, de esta forma se podría localizar, bajo DESK, información administrativa relativa al texto sujeto a una condición texto Pre-Procesador de plantillas JSP para la generación de meta- información embebida en el HTML generado.", "width": "800" } 13 Tratamiento de Reglas de Presentación { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_13.jpg", "name": "Tratamiento de Reglas de Presentación", "description": "Tratamiento de Reglas de Presentación", "width": "800" } 14 Generación de Documentos WEB en PEGASUS { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_14.jpg", "name": "Generación de Documentos WEB en PEGASUS", "description": "Generación de Documentos WEB en PEGASUS", "width": "800" } 15 Reglas de Presentación PEGASUS Gobiernan aspectos dinámicos relacionados con la renderización de los distintos objectos del dominio –Generación de enlaces –Correspondencia entre estilos de enlace y estados de objetos del dominio –Ordenación y disposición espacial de listas (de enlaces o fragmentos) –Generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Consisten en una lista de cero o más condiciones, seguidas por la presentación a aplicar cuando éstas se cumplen, descrita con la misma sintaxis de las plantillas La aplicación de las reglas es recursiva –Mayor generalidad en la renderización dinámica (respecto al caso de las modificaciones simples vistas anteriormente) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_15.jpg", "name": "Reglas de Presentación PEGASUS Gobiernan aspectos dinámicos relacionados con la renderización de los distintos objectos del dominio –Generación de enlaces –Correspondencia entre estilos de enlace y estados de objetos del dominio –Ordenación y disposición espacial de listas (de enlaces o fragmentos) –Generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Consisten en una lista de cero o más condiciones, seguidas por la presentación a aplicar cuando éstas se cumplen, descrita con la misma sintaxis de las plantillas La aplicación de las reglas es recursiva –Mayor generalidad en la renderización dinámica (respecto al caso de las modificaciones simples vistas anteriormente)", "description": "Reglas de Presentación PEGASUS Gobiernan aspectos dinámicos relacionados con la renderización de los distintos objectos del dominio –Generación de enlaces –Correspondencia entre estilos de enlace y estados de objetos del dominio –Ordenación y disposición espacial de listas (de enlaces o fragmentos) –Generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Consisten en una lista de cero o más condiciones, seguidas por la presentación a aplicar cuando éstas se cumplen, descrita con la misma sintaxis de las plantillas La aplicación de las reglas es recursiva –Mayor generalidad en la renderización dinámica (respecto al caso de las modificaciones simples vistas anteriormente)", "width": "800" } 16 Reglas de Presentación PEGASUS Sin embargo, escribir reglas es una tarea delicada que requiere cierta familiaridad con el sistema –Aunque cualquier autor con conocimientos básicos de HTML podría “retocar” una regla Herramienta de Autor necesaria => DESK –DESK posee información de alto nivel sobre lo que el autor intenta hacer en el sistema Modelo de Monitorización –DESK incorpora funcionalidad para editar aspectos cercanos al propósito de las reglas Iteración sobre objetos / Listas de objetos del dominio Inserción de condiciones sobre distintos modelos Manejo de Listas y Tablas { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_16.jpg", "name": "Reglas de Presentación PEGASUS Sin embargo, escribir reglas es una tarea delicada que requiere cierta familiaridad con el sistema –Aunque cualquier autor con conocimientos básicos de HTML podría retocar una regla Herramienta de Autor necesaria => DESK –DESK posee información de alto nivel sobre lo que el autor intenta hacer en el sistema Modelo de Monitorización –DESK incorpora funcionalidad para editar aspectos cercanos al propósito de las reglas Iteración sobre objetos / Listas de objetos del dominio Inserción de condiciones sobre distintos modelos Manejo de Listas y Tablas", "description": "Reglas de Presentación PEGASUS Sin embargo, escribir reglas es una tarea delicada que requiere cierta familiaridad con el sistema –Aunque cualquier autor con conocimientos básicos de HTML podría retocar una regla Herramienta de Autor necesaria => DESK –DESK posee información de alto nivel sobre lo que el autor intenta hacer en el sistema Modelo de Monitorización –DESK incorpora funcionalidad para editar aspectos cercanos al propósito de las reglas Iteración sobre objetos / Listas de objetos del dominio Inserción de condiciones sobre distintos modelos Manejo de Listas y Tablas", "width": "800" } 17 Gestión de Reglas de Presentación con DESK La solución podría consistir en identificar qué acciones del usuario (modelo de monitorización) son susceptibles de ser aplicadas/convertidas a reglas Identificación de la acción pertinente –Generación de enlaces, correspondencia entre estilos de enlace y estados de objetos del dominio, ordenación y disposición espacial de listas (de enlaces o fragmentos), generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Búsqueda del contexto de la acción Inferencia de los cambios sobre la “fuente” –M. Dominio, M. Presentación (Plantillas JSP + Reglas de Presentación) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_17.jpg", "name": "Gestión de Reglas de Presentación con DESK La solución podría consistir en identificar qué acciones del usuario (modelo de monitorización) son susceptibles de ser aplicadas/convertidas a reglas Identificación de la acción pertinente –Generación de enlaces, correspondencia entre estilos de enlace y estados de objetos del dominio, ordenación y disposición espacial de listas (de enlaces o fragmentos), generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Búsqueda del contexto de la acción Inferencia de los cambios sobre la fuente –M.", "description": "Dominio, M. Presentación (Plantillas JSP + Reglas de Presentación).", "width": "800" } 18 Gestión interna de Reglas en PEGASUS Fichero XML Un sub-modelo más en PEGASUS –Modelo del Dominio / Ontología del Dominio –Modelo del Usuario –Modelo de la Presentación Plantillas JSP (Templates) Sub-modelo de Reglas de Presentación El árbol JDOM se guardará en memoria –Se “cargará” junto con el resto de modelos Fichero Init.jsp Fichero Transact.jsp La ejecución y aplicación de las reglas dependerá del “Runtime” PEGASUS { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_18.jpg", "name": "Gestión interna de Reglas en PEGASUS Fichero XML Un sub-modelo más en PEGASUS –Modelo del Dominio / Ontología del Dominio –Modelo del Usuario –Modelo de la Presentación Plantillas JSP (Templates) Sub-modelo de Reglas de Presentación El árbol JDOM se guardará en memoria –Se cargará junto con el resto de modelos Fichero Init.jsp Fichero Transact.jsp La ejecución y aplicación de las reglas dependerá del Runtime PEGASUS", "description": "Gestión interna de Reglas en PEGASUS Fichero XML Un sub-modelo más en PEGASUS –Modelo del Dominio / Ontología del Dominio –Modelo del Usuario –Modelo de la Presentación Plantillas JSP (Templates) Sub-modelo de Reglas de Presentación El árbol JDOM se guardará en memoria –Se cargará junto con el resto de modelos Fichero Init.jsp Fichero Transact.jsp La ejecución y aplicación de las reglas dependerá del Runtime PEGASUS", "width": "800" } 19 Gestión interna de Reglas en PEGASUS HTML XML ++ Monitoring Model + Context Model Changes Management DESK Server-Side PEGASUS Runtime System Domain Model Presentation Model User Model HTML Monitoring Model Finding out Context DESK Front-End XML Authorized User (Enriched Monitoring Model) Ahora, Modelo de la Presentación => Plantillas +Reglas Presentation Rules ? JSP Templates { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_19.jpg", "name": "Gestión interna de Reglas en PEGASUS HTML XML ++ Monitoring Model + Context Model Changes Management DESK Server-Side PEGASUS Runtime System Domain Model Presentation Model User Model HTML Monitoring Model Finding out Context DESK Front-End XML Authorized User (Enriched Monitoring Model) Ahora, Modelo de la Presentación => Plantillas +Reglas Presentation Rules .", "description": "JSP Templates.", "width": "800" } 20 Uso de Reglas, pautas generales Necesaria una estructura general para definirlas –Matching => Representa a partir de qué Objeto del Dominio se va a buscar una similitud –Ámbito de Aplicación => Para identificar estados especiales sobre los Objetos del Dominio a modificar –Condición de Aplicación => Selecciona qué Objetos del “Matching” serán alterados con la nueva presentación a aplicar –Nueva Presentación a Aplicar => Nuevas etiquetas para modificar la presentación sobre el Objeto del Dominio Rule { Matching {...} Ámbito de Aplicación {...} Condición de Aplicación {...} Nueva Presentación a Aplicar {...} } { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_20.jpg", "name": "Uso de Reglas, pautas generales Necesaria una estructura general para definirlas –Matching => Representa a partir de qué Objeto del Dominio se va a buscar una similitud –Ámbito de Aplicación => Para identificar estados especiales sobre los Objetos del Dominio a modificar –Condición de Aplicación => Selecciona qué Objetos del Matching serán alterados con la nueva presentación a aplicar –Nueva Presentación a Aplicar => Nuevas etiquetas para modificar la presentación sobre el Objeto del Dominio Rule { Matching {...} Ámbito de Aplicación {...} Condición de Aplicación {...} Nueva Presentación a Aplicar {...} }", "description": "Uso de Reglas, pautas generales Necesaria una estructura general para definirlas –Matching => Representa a partir de qué Objeto del Dominio se va a buscar una similitud –Ámbito de Aplicación => Para identificar estados especiales sobre los Objetos del Dominio a modificar –Condición de Aplicación => Selecciona qué Objetos del Matching serán alterados con la nueva presentación a aplicar –Nueva Presentación a Aplicar => Nuevas etiquetas para modificar la presentación sobre el Objeto del Dominio Rule { Matching {...} Ámbito de Aplicación {...} Condición de Aplicación {...} Nueva Presentación a Aplicar {...} }", "width": "800" } 21 Uso de Reglas, pautas generales (y II) Estado “inicial” de la presentación –Estado por defecto, se ejecutará y se guardará antes de que cualquier regla cambie el “estado” de la presentación (Ejemplo: prerequisites.tree() ) –Generado por HADES. Módulo de creación de los modelos por defecto (Modelo de la Presentación) Se creará un protocolo, a partir de métodos, para alterar el estado de la visualización –Métodos bien definidos, construidos homogéneamente. –La “renderización” podrá alterarse a partir del paso de mensajes entre objetos del dominio prerequisites.tree(“Horizontal”) prerequisites.tree(“Vertical”) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_21.jpg", "name": "Uso de Reglas, pautas generales (y II) Estado inicial de la presentación –Estado por defecto, se ejecutará y se guardará antes de que cualquier regla cambie el estado de la presentación (Ejemplo: prerequisites.tree() ) –Generado por HADES.", "description": "Módulo de creación de los modelos por defecto (Modelo de la Presentación) Se creará un protocolo, a partir de métodos, para alterar el estado de la visualización –Métodos bien definidos, construidos homogéneamente. –La renderización podrá alterarse a partir del paso de mensajes entre objetos del dominio prerequisites.tree( Horizontal ) prerequisites.tree( Vertical ).", "width": "800" } 22 Ejemplos de Uso Ejemplo 1 –Modificación de los colores de los links “ya utilizados” por el usuario en la presentación Ejemplo 2 –El usuario decide cambiar la forma de ver los links HTML para transformarlos en una lista ordenada de links { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_22.jpg", "name": "Ejemplos de Uso Ejemplo 1 –Modificación de los colores de los links ya utilizados por el usuario en la presentación Ejemplo 2 –El usuario decide cambiar la forma de ver los links HTML para transformarlos en una lista ordenada de links", "description": "Ejemplos de Uso Ejemplo 1 –Modificación de los colores de los links ya utilizados por el usuario en la presentación Ejemplo 2 –El usuario decide cambiar la forma de ver los links HTML para transformarlos en una lista ordenada de links", "width": "800" } 23 Ejemplo de Uso 1 1) El usuario, bajo DESK, selecciona un link “ya utilizado” de una lista para cambiar el color de dicho link 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End) Quizás sobraría para este tipo de casos / relaciones complejas... Plantilla JSP Página HTML generada Pre-Procesamiento.", "width": "800" } 26 Ejemplo de Uso 1 (y IV) Posible Solución IIPosible Solución II –Realizar “matching” con la parte “Presentation” de las Reglas, hasta encontrar exactamente cual es la regla que se pretende cambiar. Esta solución es más directa y además ayudaría a localizar mucho mejor la regla que se prende cambiar. Ejemplo: 27 Ejemplo de Uso 2 1) El usuario, bajo DESK, selecciona un conjunto de links HTML para crear una lista 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_28.jpg", "name": "Ejemplo de Uso 2 (II) 4) DESK Infiere conocimiento que le permite decidir el modificar directamente el sub-modelo de Reglas de Presentación para crear una nueva regla que afecte a la visualización de los links para la lista de pre-requisitos Nueva Regla de Presentación ", "description": "Ejemplo de Uso 2 (II) 4) DESK Infiere conocimiento que le permite decidir el modificar directamente el sub-modelo de Reglas de Presentación para crear una nueva regla que afecte a la visualización de los links para la lista de pre-requisitos Nueva Regla de Presentación ", "width": "800" } 29 Ejemplo de Uso 2 (y III) ComentariosComentarios –Este tipo de ejemplo, donde entra en juego la generación de una nueva regla, no es factible de momento Creación de reglas => solución poco general => para resolver siempre los mismos casos => Habría que generalizar y “factorizar” con respecto a reglas ya creadas Es posible que no se disponga de suficiente información para generar reglas en tiempo real Para justificar la creación de nuevas reglas sería necesaria la intervención de, por ejemplo, el Modelo de Usuario, para poder crear reglas de ámbito y funcionalidad más generales –La forma de hacer esto bajo DESK no sería demasiado WYSIWYG { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_29.jpg", "name": "Ejemplo de Uso 2 (y III) ComentariosComentarios –Este tipo de ejemplo, donde entra en juego la generación de una nueva regla, no es factible de momento Creación de reglas => solución poco general => para resolver siempre los mismos casos => Habría que generalizar y factorizar con respecto a reglas ya creadas Es posible que no se disponga de suficiente información para generar reglas en tiempo real Para justificar la creación de nuevas reglas sería necesaria la intervención de, por ejemplo, el Modelo de Usuario, para poder crear reglas de ámbito y funcionalidad más generales –La forma de hacer esto bajo DESK no sería demasiado WYSIWYG", "description": "Ejemplo de Uso 2 (y III) ComentariosComentarios –Este tipo de ejemplo, donde entra en juego la generación de una nueva regla, no es factible de momento Creación de reglas => solución poco general => para resolver siempre los mismos casos => Habría que generalizar y factorizar con respecto a reglas ya creadas Es posible que no se disponga de suficiente información para generar reglas en tiempo real Para justificar la creación de nuevas reglas sería necesaria la intervención de, por ejemplo, el Modelo de Usuario, para poder crear reglas de ámbito y funcionalidad más generales –La forma de hacer esto bajo DESK no sería demasiado WYSIWYG", "width": "800" } 30 Tratamiento de la Batería de Reglas Agosto 2002 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_30.jpg", "name": "Tratamiento de la Batería de Reglas Agosto 2002", "description": "Tratamiento de la Batería de Reglas Agosto 2002", "width": "800" } 31 Análisis Previo ¿Cómo puede DESK inferir cambios en las Reglas de Presentación a partir de cambios que usuario realiza en la presentación? –Mediante la utilización de Primitivas Directas Permite un control más preciso sobre lo que el usuario puede hacer El mecanismo de inferencia es más directo y menos ambiguo Mayor comodidad para el usuario sobre todo si este es poco experto (DESK lo hace todo con una sola acción) Se pierte naturalidad al acercarse más al sistema Pregunta filosófica: ¿Merece la pena hacer Programación. Por Demostración?: Depende, quizás algunas veces si, aunque no hay que dejarlo todo en manos de un motor de inferencia –Mediante la detección de cambios indirectos (en varios pasos) que afectarán (en su totalidad) a alguna Regla de Presentación Necesario interpretar y analizar el Modelo de Monitorización Se eleva el número de ambigüedades que se pueden producir Esta opción es bastante interesante de cara a la Program. por Demostración { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_31.jpg", "name": "Análisis Previo ¿Cómo puede DESK inferir cambios en las Reglas de Presentación a partir de cambios que usuario realiza en la presentación.", "description": "–Mediante la utilización de Primitivas Directas Permite un control más preciso sobre lo que el usuario puede hacer El mecanismo de inferencia es más directo y menos ambiguo Mayor comodidad para el usuario sobre todo si este es poco experto (DESK lo hace todo con una sola acción) Se pierte naturalidad al acercarse más al sistema Pregunta filosófica: ¿Merece la pena hacer Programación. Por Demostración : Depende, quizás algunas veces si, aunque no hay que dejarlo todo en manos de un motor de inferencia –Mediante la detección de cambios indirectos (en varios pasos) que afectarán (en su totalidad) a alguna Regla de Presentación Necesario interpretar y analizar el Modelo de Monitorización Se eleva el número de ambigüedades que se pueden producir Esta opción es bastante interesante de cara a la Program. por Demostración.", "width": "800" } 32 Análisis Previo (II) ¿Todas las reglas son susceptibles de ser modificadas? –Elaborar un conjunto de primitivas lo suficientemente amplio que recojan las distintas correspondencias entre el cambio llevado a cabo por el usuario y tipo de Regla a modificar –Estructuras más susceptibles de ser aplicadas/generadas por reglas Listas de Elementos (Enumeraciones) (Grafos, Árboles) Tablas Estilos de los links Widgets (inputs, botones...) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_32.jpg", "name": "Análisis Previo (II) ¿Todas las reglas son susceptibles de ser modificadas.", "description": "–Elaborar un conjunto de primitivas lo suficientemente amplio que recojan las distintas correspondencias entre el cambio llevado a cabo por el usuario y tipo de Regla a modificar –Estructuras más susceptibles de ser aplicadas/generadas por reglas Listas de Elementos (Enumeraciones) (Grafos, Árboles) Tablas Estilos de los links Widgets (inputs, botones...).", "width": "800" } 33 Análisis Previo (III) Problema –La mayoría de las reglas hacen referencia a relaciones complejas entre objetos ( prerequisites, courses, etc.) que son difíciles de ser detectadas a partir del la edición en DESK, incluso en el Back-End, utilizando la información de los modelos existentes Solución –Utilizar un pre-procesamiento, en PEGASUS, a la hora de generar el código HTML a partir de las Reglas o los métodos de objetos de alto nivel ( prerequisites.tree(“Horizontal”) ) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_33.jpg", "name": "Análisis Previo (III) Problema –La mayoría de las reglas hacen referencia a relaciones complejas entre objetos ( prerequisites, courses, etc.) que son difíciles de ser detectadas a partir del la edición en DESK, incluso en el Back-End, utilizando la información de los modelos existentes Solución –Utilizar un pre-procesamiento, en PEGASUS, a la hora de generar el código HTML a partir de las Reglas o los métodos de objetos de alto nivel ( prerequisites.tree( Horizontal ) )", "description": "Análisis Previo (III) Problema –La mayoría de las reglas hacen referencia a relaciones complejas entre objetos ( prerequisites, courses, etc.) que son difíciles de ser detectadas a partir del la edición en DESK, incluso en el Back-End, utilizando la información de los modelos existentes Solución –Utilizar un pre-procesamiento, en PEGASUS, a la hora de generar el código HTML a partir de las Reglas o los métodos de objetos de alto nivel ( prerequisites.tree( Horizontal ) )", "width": "800" } 34 Análisis Previo (IV) Regla 1... Regla N Reglas de Presentación Plantilla i Plantillas JSP Meta Información Etiquetas HTML Pre-Procesamiento Documento HTML Final Modelo de la Presentación Pre-procesamiento del documento HTML antes de ser enviado Al usuario final - Dependerá de PEGASUS - Sobre-escritura del “Writer” JSP PEGASUS { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_34.jpg", "name": "Análisis Previo (IV) Regla 1...", "description": "Regla N Reglas de Presentación Plantilla i Plantillas JSP Meta Información Etiquetas HTML Pre-Procesamiento Documento HTML Final Modelo de la Presentación Pre-procesamiento del documento HTML antes de ser enviado Al usuario final - Dependerá de PEGASUS - Sobre-escritura del Writer JSP PEGASUS.", "width": "800" } 35 Análisis Previo (V) ¿Qué tipo de meta-información sería útil añadir al HTML Final? –Datos sobre estructuras especiales generadas dinámicamente y cuyo reconocimiento no sea obvio con la información disponible en DESK Listas y Tablas de Elementos generadas a partir de Relaciones Multivaluadas ¿Dónde debería ir codificada esa información? –Como atributos de dichas estructuras (Tablas, Listas), éstos atributos pueden ser reconocidos perfectamente por DESK –Pensar en una extensión del HTML, que es perfectamente “browseable”, con nombre propio, y detallar su DTD ¿Qué codificaría dicha información? –Datos de alto nivel cuya obtención no resulte trivial a partir de los distintos modelos PEGASUS Nombre de la Relación Multivaluada Código de Regla a partir de la cual ha sido generado el fragmento HTML Otros datos, dependiendo de la fuente que generó dicho fragmento HTML –Condiciones sobre el modelo de Usuario u otros modelos existentes –Número de ítems afectados en la evaluación de la Regla –Etc. { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_35.jpg", "name": "Análisis Previo (V) ¿Qué tipo de meta-información sería útil añadir al HTML Final.", "description": "–Datos sobre estructuras especiales generadas dinámicamente y cuyo reconocimiento no sea obvio con la información disponible en DESK Listas y Tablas de Elementos generadas a partir de Relaciones Multivaluadas ¿Dónde debería ir codificada esa información. –Como atributos de dichas estructuras (Tablas, Listas), éstos atributos pueden ser reconocidos perfectamente por DESK –Pensar en una extensión del HTML, que es perfectamente browseable , con nombre propio, y detallar su DTD ¿Qué codificaría dicha información. –Datos de alto nivel cuya obtención no resulte trivial a partir de los distintos modelos PEGASUS Nombre de la Relación Multivaluada Código de Regla a partir de la cual ha sido generado el fragmento HTML Otros datos, dependiendo de la fuente que generó dicho fragmento HTML –Condiciones sobre el modelo de Usuario u otros modelos existentes –Número de ítems afectados en la evaluación de la Regla –Etc..", "width": "800" } 36 Análisis Previo (VI) Por Ejemplo, el siguiente código en plantilla JSP: prerequisites.tree(“Vertical”) Podría generar el siguiente HTML Final: { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_36.jpg", "name": "Análisis Previo (VI) Por Ejemplo, el siguiente código en plantilla JSP: prerequisites.tree( Vertical ) Podría generar el siguiente HTML Final: .", "width": "800" } 37 Análisis Previo (VII) 1) El usuario, bajo DESK, selecciona el texto de una lista para cambiar la disposición de los elementos, de vertical a horizontal 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End) 38 Análisis Previo (VIII) Modelo de la Presentación Original 3) DESK modifica directamente el modelo de la Presentación, mediante el uso del protocolo de paso de mensajes entre objetos del dominio (Back-End) Modelo de la Presentación Modificado......... { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_38.jpg", "name": "Análisis Previo (VIII) Modelo de la Presentación Original 3) DESK modifica directamente el modelo de la Presentación, mediante el uso del protocolo de paso de mensajes entre objetos del dominio (Back-End) Modelo de la Presentación Modificado.........", "description": "Análisis Previo (VIII) Modelo de la Presentación Original 3) DESK modifica directamente el modelo de la Presentación, mediante el uso del protocolo de paso de mensajes entre objetos del dominio (Back-End) Modelo de la Presentación Modificado.........", "width": "800" } 39 Análisis Previo (y IX) Esta misma filosofía podría ser aplicada a las Reglas –Codificándolas (o que lo haga PEGASUS internamente): –Para luego poder ser identificadas en DESK: –Esto Permitiría el encontrar, de una forma mucho más directa, la regla que se desea cambiar, sin necesidad de hacer “matching” en la parte de Presentación de la Regla (solución propuesta en la transparencia 26) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_39.jpg", "name": "Análisis Previo (y IX) Esta misma filosofía podría ser aplicada a las Reglas –Codificándolas (o que lo haga PEGASUS internamente): –Para luego poder ser identificadas en DESK: –Esto Permitiría el encontrar, de una forma mucho más directa, la regla que se desea cambiar, sin necesidad de hacer matching en la parte de Presentación de la Regla (solución propuesta en la transparencia 26) ...", "description": " Relaxation Method....", "width": "800" } 40 Reglas de Generación de Tablas y Listas Generan Tablas y Listas a partir de la iteración sobre elementos de una Relación Multivaluada Se pueden tratar siempre y cuando se genere meta-información adicional sobre ellas (id, tipo, relación afectada, cobertura,...) Las que vienen modelizadas a un nivel de especificación mayor son las más susceptibles de ser tratadas, y son las que pueden dar más juego a la hora de modificar distintos campos de las mismas. –Iteración directa sobre campos ( course.year... ) => nº de campo –Especificación directa en la creación ( makeTable, makeTree ) Al contrario que las otras, donde los cambios serían más globales (,... ) al menos que no estén lo suficientemente parametrizados { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_40.jpg", "name": "Reglas de Generación de Tablas y Listas Generan Tablas y Listas a partir de la iteración sobre elementos de una Relación Multivaluada Se pueden tratar siempre y cuando se genere meta-información adicional sobre ellas (id, tipo, relación afectada, cobertura,...) Las que vienen modelizadas a un nivel de especificación mayor son las más susceptibles de ser tratadas, y son las que pueden dar más juego a la hora de modificar distintos campos de las mismas.", "description": "–Iteración directa sobre campos ( course.year... ) => nº de campo –Especificación directa en la creación ( makeTable, makeTree ) Al contrario que las otras, donde los cambios serían más globales (,... ) al menos que no estén lo suficientemente parametrizados.", "width": "800" } 41 Ejemplo Número 1 Course name Year Teacher Room Schedule > Course name Year Teacher Room Schedule OOP 2001-2002 P. Castells A-201 1.- Introduction 2.-... Operating Systems I 2001-2002 J. A. Macías A-202 1.- Introduction 2.-...... ReglaPosible Código Generado (HTML Final) Podría incluso guardarse el nombre de la variable sobre la que se itera: var_name = “course” Este tipo de “Reglas” podrían ir directamente en la plantilla JSP { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_41.jpg", "name": "Ejemplo Número 1 Course name Year Teacher Room Schedule > Course name Year Teacher Room Schedule OOP 2001-2002 P.", "description": "Castells A-201 1.- Introduction 2.-... Operating Systems I 2001-2002 J. A. Macías A-202 1.- Introduction 2.-...... ReglaPosible Código Generado (HTML Final) Podría incluso guardarse el nombre de la variable sobre la que se itera: var_name = course Este tipo de Reglas podrían ir directamente en la plantilla JSP.", "width": "800" } 42 Ejemplo Número 1 (y II) Tratamiento bajo DESK (A partir del HTML Final) –El usuario hace un cambio sobre la tabla (por ejemplo: cambiar el color del año de los cursos) DESK Fron-End sabe que la tabla ha sido generada a partir de una Regla (R01), además la Relación Multivaluada es identificada igualmente (courses) En este caso, saber el Atributo modificado es fácil, solamente hay que saber qué columna es la que se ha modificado (nº 2 => year). La fila puede indicar si se trata de los títulos o de la inf. dinámica –En el caso de que la variable de iteración se corresponda con el nombre del objeto, DESK Back-End podría buscar el contexto del cambio y encontrará el Atributo “year” del Objeto “course” DESK busca en la Regla R01, la iteración sobre “courses” y en concreto el Atributo “course.year”, añadiendo la modificación deseada:...... { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_42.jpg", "name": "Ejemplo Número 1 (y II) Tratamiento bajo DESK (A partir del HTML Final) –El usuario hace un cambio sobre la tabla (por ejemplo: cambiar el color del año de los cursos) DESK Fron-End sabe que la tabla ha sido generada a partir de una Regla (R01), además la Relación Multivaluada es identificada igualmente (courses) En este caso, saber el Atributo modificado es fácil, solamente hay que saber qué columna es la que se ha modificado (nº 2 => year).", "description": "La fila puede indicar si se trata de los títulos o de la inf. dinámica –En el caso de que la variable de iteración se corresponda con el nombre del objeto, DESK Back-End podría buscar el contexto del cambio y encontrará el Atributo year del Objeto course DESK busca en la Regla R01, la iteración sobre courses y en concreto el Atributo course.year , añadiendo la modificación deseada:.......", "width": "800" } 43 Ejemplo Número 2 > > > > > Reglas Creación Genérica De Tablas de forma Vertical y Horizontal Este tipo de “Reglas” podrían ir directamente en la plantilla JSP { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_43.jpg", "name": "Ejemplo Número 2 > > > > > Reglas Creación Genérica De Tablas de forma Vertical y Horizontal Este tipo de Reglas podrían ir directamente en la plantilla JSP", "description": "Ejemplo Número 2 > > > > > Reglas Creación Genérica De Tablas de forma Vertical y Horizontal Este tipo de Reglas podrían ir directamente en la plantilla JSP", "width": "800" } 44 Ejemplo Número 2 (y II) Este tipo de Regla da menos juego a la hora de realizar cambios bajo DESK –Especificación demasiado genérica –No existen “campos” o Atributos “tangibles” Poco juego a la hora de manipular e inferir qué datos son los que han cambiado partiendo del HTML final en DESK Posible Solución / Mejora –Añadir más meta-información sobre lo generado (codif. campos) –Mayor parametrización en la parte de la Regla Esto puede dar más juego a la hora de realizar cambios mediante el protocolo de paso de mensajes (alteración del estado/funcionalidad) Cambios Posibles desde DESK –Conversión Tabla Vertical => Tabla Horizontal => Lista Siempre y cuando el aspecto de la regla sea “fijo”, se podrían tener patrones de este tipo de reglas para una conversión en el Layout { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_44.jpg", "name": "Ejemplo Número 2 (y II) Este tipo de Regla da menos juego a la hora de realizar cambios bajo DESK –Especificación demasiado genérica –No existen campos o Atributos tangibles Poco juego a la hora de manipular e inferir qué datos son los que han cambiado partiendo del HTML final en DESK Posible Solución / Mejora –Añadir más meta-información sobre lo generado (codif.", "description": "campos) –Mayor parametrización en la parte de la Regla Esto puede dar más juego a la hora de realizar cambios mediante el protocolo de paso de mensajes (alteración del estado/funcionalidad) Cambios Posibles desde DESK –Conversión Tabla Vertical => Tabla Horizontal => Lista Siempre y cuando el aspecto de la regla sea fijo , se podrían tener patrones de este tipo de reglas para una conversión en el Layout.", "width": "800" } 45 Ejemplo Número 3 fields = {"name","year","credits","contents"} order-by = "year" orientation = "vertical"/> fields = {"name","students"{"name","address"{"street","city","zipCode"}}}/> Reglas Este otro tipo de Reglas pueden dar bastante juego a la hora de cambiar el orden y la forma de creación de los elementos, debido al alto nivel de especificación con el que han sido definidas. La del Ejemplo número 1 también, pero quizás sería algo más costoso. Si la sintaxis fuera más flexible, incluso se podrían realizar cambios en el estilo (color, fuente, etc.) de los ítems Este tipo de “Reglas” podrían ir directamente en la plantilla JSP, y suelen preceder a las vistas anteriormente (definen los campos sobre los que iterar) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_45.jpg", "name": "Ejemplo Número 3 fields = { name , year , credits , contents } order-by = year orientation = vertical /> fields = { name , students { name , address { street , city , zipCode }}}/> Reglas Este otro tipo de Reglas pueden dar bastante juego a la hora de cambiar el orden y la forma de creación de los elementos, debido al alto nivel de especificación con el que han sido definidas.", "description": "La del Ejemplo número 1 también, pero quizás sería algo más costoso. Si la sintaxis fuera más flexible, incluso se podrían realizar cambios en el estilo (color, fuente, etc.) de los ítems Este tipo de Reglas podrían ir directamente en la plantilla JSP, y suelen preceder a las vistas anteriormente (definen los campos sobre los que iterar).", "width": "800" } 46 Ejemplo Número 3 (y II) Realizar este tipo de cambios sería tan fácil como detectarlos a nivel de edición (drag-drop), codificando el cambio: (Name Year) Lo que modificaría directamente la regla en cuestión: –Otros cambios: Ordenación, Orientación, Profundidad... { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_46.jpg", "name": "Ejemplo Número 3 (y II) Realizar este tipo de cambios sería tan fácil como detectarlos a nivel de edición (drag-drop), codificando el cambio: (Name Year) Lo que modificaría directamente la regla en cuestión: –Otros cambios: Ordenación, Orientación, Profundidad...", "description": ".", "width": "800" } 47 Ejemplo Número 4 15"/> fields()"/> 5"/>... Reglas Reglas sujetas a condiciones sobre la visualización de ciertos datos, en forma de lista o tabla { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_47.jpg", "name": "Ejemplo Número 4 15 /> fields() /> 5 />...", "description": "Reglas Reglas sujetas a condiciones sobre la visualización de ciertos datos, en forma de lista o tabla.", "width": "800" } 48 Ejemplo Número 4 (II) Se comentaron el el apartado de “Análisis Previo” La forma de identificarlas es mediante la generación de meta- información apropiada, de forma que puedan ser identificadas bajo DESK e inferir su cambio posteriormente –Código y Tipo de Regla –Relación Multivaluada –Nombre de la Clase Los cambios sobre estas Reglas pueden venir dados en forma de primitivas que permitan –Cambiar el layout (“ vertical ”, “ horizontal ”, “ asTable ”...) –Cambiar el contenido (“ this.map(“title”) ”) –Cambiar algunas de las condiciones de activación / visualización ( length(), orientation... ) Quizás esto requeriría de una “edición avanzada” => Por ejemplo: el usuario introduce una línea más y DESK infiere que se pretende cambiar (dentro del código afectado por la regla) la condición de activación de la regla ( length()>N+1 ) Esto quizás es solamente útil para casos de generación directa: prerequisistes.tree(“Vertical”) } { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_48.jpg", "name": "Ejemplo Número 4 (II) Se comentaron el el apartado de Análisis Previo La forma de identificarlas es mediante la generación de meta- información apropiada, de forma que puedan ser identificadas bajo DESK e inferir su cambio posteriormente –Código y Tipo de Regla –Relación Multivaluada –Nombre de la Clase Los cambios sobre estas Reglas pueden venir dados en forma de primitivas que permitan –Cambiar el layout ( vertical , horizontal , asTable ...) –Cambiar el contenido ( this.map( title ) ) –Cambiar algunas de las condiciones de activación / visualización ( length(), orientation...", "description": ") Quizás esto requeriría de una edición avanzada => Por ejemplo: el usuario introduce una línea más y DESK infiere que se pretende cambiar (dentro del código afectado por la regla) la condición de activación de la regla ( length()>N+1 ) Esto quizás es solamente útil para casos de generación directa: prerequisistes.tree( Vertical ) }.", "width": "800" } 49 Ejemplo Número 4 (III) 1) El usuario, bajo DESK, selecciona un link “ya utilizado” de una lista para cambiar el color de dicho link 2) La Lista ha sido generada a partir de la Regla con ID = R10, DESK lo detecta y crea una entrada en el Modelo de Monitorización 50 Ejemplo Número 4 (y IV) Regla de Presentación Original 4) DESK Back-End utiliza el conocimiento disponible en el Modelo de Monitorización, el cual le permite decidir el modificar directamente la Regla de Presentación, para cambiar el color de los links “ya usados” (Asociación: Change_Color => cambio en ) Regla de Presentación Modificada { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_50.jpg", "name": "Ejemplo Número 4 (y IV) Regla de Presentación Original 4) DESK Back-End utiliza el conocimiento disponible en el Modelo de Monitorización, el cual le permite decidir el modificar directamente la Regla de Presentación, para cambiar el color de los links ya usados (Asociación: Change_Color => cambio en ) Regla de Presentación Modificada ", "description": "Ejemplo Número 4 (y IV) Regla de Presentación Original 4) DESK Back-End utiliza el conocimiento disponible en el Modelo de Monitorización, el cual le permite decidir el modificar directamente la Regla de Presentación, para cambiar el color de los links ya usados (Asociación: Change_Color => cambio en ) Regla de Presentación Modificada ", "width": "800" } 51 Ampliaciones / Conclusiones ¿Por qué no utilizar siempre meta-información en vez de buscar en el Modelo del Dominio? –Justificación El basar la búsqueda en Meta-Información hace el proceso de inferencia más lento en el Cliente (Front-End), siendo además más complejo y tedioso (sería necesario localizar las etiquetas con algoritmos de búsqueda de contexto) Esto no se pensó así desde el principio, por eso podría funcionar de las dos formas (poniendo meta-información y sin ponerla y buscándola DESK). Una nueva versión de PEGASUS debería pues generar la meta-información El colocar meta-información también ayuda a localizar inserciones-borrados en DESK, para luego poderlos trasladar a la plantilla (ahora se sabe qué objeto ha generado cada párrafo y es fácil situar los cambios) Para reglas, se podría utilizar un “tag” más genérico:, en vez de añadir atributos. Esto es bastante útil si la generación de una misma regla engloba a varios bloques (varias tablas, literales-cadenas y listas) –Quizás, en resumen, sería conveniente utilizar Meta-Información exclusivamente para el tratamiento de Reglas de Presentación { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_51.jpg", "name": "Ampliaciones / Conclusiones ¿Por qué no utilizar siempre meta-información en vez de buscar en el Modelo del Dominio.", "description": "–Justificación El basar la búsqueda en Meta-Información hace el proceso de inferencia más lento en el Cliente (Front-End), siendo además más complejo y tedioso (sería necesario localizar las etiquetas con algoritmos de búsqueda de contexto) Esto no se pensó así desde el principio, por eso podría funcionar de las dos formas (poniendo meta-información y sin ponerla y buscándola DESK). Una nueva versión de PEGASUS debería pues generar la meta-información El colocar meta-información también ayuda a localizar inserciones-borrados en DESK, para luego poderlos trasladar a la plantilla (ahora se sabe qué objeto ha generado cada párrafo y es fácil situar los cambios) Para reglas, se podría utilizar un tag más genérico:, en vez de añadir atributos. Esto es bastante útil si la generación de una misma regla engloba a varios bloques (varias tablas, literales-cadenas y listas) –Quizás, en resumen, sería conveniente utilizar Meta-Información exclusivamente para el tratamiento de Reglas de Presentación.", "width": "800" } 52 Ampliaciones/Conclusiones (II) –Problemas 1. El usuario podría, mediante DESK, editar (insertar elementos, cadenas...) entre, por ejemplo, la etiqueta de contexto de la Regla y la definición de una tabla, o entre cualquiera de los elementos que engloban el bloque 2. ¿Qué pasa si convertimos una lista de elementos a una colección de párrafos (no-lista)? –Podría perderse la información sobre Regla que generó el bloque –Posibles Soluciones: 1. Para ciertos cambios sobre reglas, no importa demasiado que el usuario añada un EOL o una nueva línea dentro de un bloque-regla –Pues se buscan acciones y datos muy concretos (ID-Regla, Primitiva de Cambio (color, intercambio de elementos, alteración del orden o del layout)) –En cualquier caso, cada elemento dentro de podría llevar el código de Regla (o subcódigo) y el orden de aparición, para evitar perder la secuencia si un usuario introduce ítems “extraños” dentro 2. No importa que los elementos pierdan la estructura, siempre que se siga conservando el o los atributos (aunque haya que crear un párrafo para la persistencia de los atributos) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_52.jpg", "name": "Ampliaciones/Conclusiones (II) –Problemas 1.", "description": "El usuario podría, mediante DESK, editar (insertar elementos, cadenas...) entre, por ejemplo, la etiqueta de contexto de la Regla y la definición de una tabla, o entre cualquiera de los elementos que engloban el bloque 2. ¿Qué pasa si convertimos una lista de elementos a una colección de párrafos (no-lista). –Podría perderse la información sobre Regla que generó el bloque –Posibles Soluciones: 1. Para ciertos cambios sobre reglas, no importa demasiado que el usuario añada un EOL o una nueva línea dentro de un bloque-regla –Pues se buscan acciones y datos muy concretos (ID-Regla, Primitiva de Cambio (color, intercambio de elementos, alteración del orden o del layout)) –En cualquier caso, cada elemento dentro de podría llevar el código de Regla (o subcódigo) y el orden de aparición, para evitar perder la secuencia si un usuario introduce ítems extraños dentro 2. No importa que los elementos pierdan la estructura, siempre que se siga conservando el o los atributos (aunque haya que crear un párrafo para la persistencia de los atributos).", "width": "800" } 53 Ampliaciones/Conclusiones (III) Intentar llegar a un “consenso” para modelizar las acciones que llevan a cabo las reglas –De esta forma se podrían crear primitivas asociadas a cada acción –Protocolo coherente ( change_color, change_orientation_to_vertical,...) Los elementos de una lista se puedan re-ordenar a partir de criterios establecidos en una regla –El usuario podría hacerlo desde DESK, mediante un algoritmos de ordenación de cadenas a partir de un criterio dado. –Es interesante decir que DESK diferencia qué tipo de acción se está dando e infiere información distinta dependiendo de la precedencia de la estructura (Regla, lista genérica definida por el usuario, tabla,...) Enumerar qué tipos/casos de acciones se pueden realizar sobre listas/tablas { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_53.jpg", "name": "Ampliaciones/Conclusiones (III) Intentar llegar a un consenso para modelizar las acciones que llevan a cabo las reglas –De esta forma se podrían crear primitivas asociadas a cada acción –Protocolo coherente ( change_color, change_orientation_to_vertical,...) Los elementos de una lista se puedan re-ordenar a partir de criterios establecidos en una regla –El usuario podría hacerlo desde DESK, mediante un algoritmos de ordenación de cadenas a partir de un criterio dado.", "description": "–Es interesante decir que DESK diferencia qué tipo de acción se está dando e infiere información distinta dependiendo de la precedencia de la estructura (Regla, lista genérica definida por el usuario, tabla,...) Enumerar qué tipos/casos de acciones se pueden realizar sobre listas/tablas.", "width": "800" } 54 Ampliaciones/Conclusiones (IV) Se podría crear un módulo de edición interactivo de Reglas –Por ejemplo: el usuario hace “doble click” sobre un fragmento generado a partir de una Regla, seguidamente aparece una ventana para cambiar las propiedades de generación / activación de la Regla Esto implicaría una modelización uniforme de las Reglas para que puedan ser tratadas homogéneamente –Este caso es parecido al de la creación de condiciones sobre el Modelo del Usuario y de la Plataforma (visto anteriormente) Sería necesario disponer del Modelo de Reglas en el Front-End Posible pérdida del WYSIWYG en la edición { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_54.jpg", "name": "Ampliaciones/Conclusiones (IV) Se podría crear un módulo de edición interactivo de Reglas –Por ejemplo: el usuario hace doble click sobre un fragmento generado a partir de una Regla, seguidamente aparece una ventana para cambiar las propiedades de generación / activación de la Regla Esto implicaría una modelización uniforme de las Reglas para que puedan ser tratadas homogéneamente –Este caso es parecido al de la creación de condiciones sobre el Modelo del Usuario y de la Plataforma (visto anteriormente) Sería necesario disponer del Modelo de Reglas en el Front-End Posible pérdida del WYSIWYG en la edición", "description": "Ampliaciones/Conclusiones (IV) Se podría crear un módulo de edición interactivo de Reglas –Por ejemplo: el usuario hace doble click sobre un fragmento generado a partir de una Regla, seguidamente aparece una ventana para cambiar las propiedades de generación / activación de la Regla Esto implicaría una modelización uniforme de las Reglas para que puedan ser tratadas homogéneamente –Este caso es parecido al de la creación de condiciones sobre el Modelo del Usuario y de la Plataforma (visto anteriormente) Sería necesario disponer del Modelo de Reglas en el Front-End Posible pérdida del WYSIWYG en la edición", "width": "800" } 55 Ampliaciones/Conclusiones (V) En general, se podrían englobar las acciones no WYSIWYG relacionadas con la edición abstracta basada en modelos –Tipos: Modelado del Usuario y de la Plataforma Edición y modificación directa del Sub-Modelo de Reglas Cambios a partir de la Edición directa sobre otros modelos –Utilizando acceso directo a los modelos o, quizás, añadiendo Meta-Información sobre los mismos para realizar posteriormente los cambios en el Back-End { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_55.jpg", "name": "Ampliaciones/Conclusiones (V) En general, se podrían englobar las acciones no WYSIWYG relacionadas con la edición abstracta basada en modelos –Tipos: Modelado del Usuario y de la Plataforma Edición y modificación directa del Sub-Modelo de Reglas Cambios a partir de la Edición directa sobre otros modelos –Utilizando acceso directo a los modelos o, quizás, añadiendo Meta-Información sobre los mismos para realizar posteriormente los cambios en el Back-End", "description": "Ampliaciones/Conclusiones (V) En general, se podrían englobar las acciones no WYSIWYG relacionadas con la edición abstracta basada en modelos –Tipos: Modelado del Usuario y de la Plataforma Edición y modificación directa del Sub-Modelo de Reglas Cambios a partir de la Edición directa sobre otros modelos –Utilizando acceso directo a los modelos o, quizás, añadiendo Meta-Información sobre los mismos para realizar posteriormente los cambios en el Back-End", "width": "800" } 56 Ejemplo Práctico Septiembre - 2002 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_56.jpg", "name": "Ejemplo Práctico Septiembre - 2002", "description": "Ejemplo Práctico Septiembre - 2002", "width": "800" } 57 Caso a Estudiar Página WEB de Tucows, con distinto tipo de Software para Internet Categoría principal: Internet –Distintas categorías y sub- categorías –Posible Ontología: En forma de árbol Flap / Category / Sub-Category Product –Nodo final / hoja. Producto en concreto para ser descargado o comprado por el usuario { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_57.jpg", "name": "Caso a Estudiar Página WEB de Tucows, con distinto tipo de Software para Internet Categoría principal: Internet –Distintas categorías y sub- categorías –Posible Ontología: En forma de árbol Flap / Category / Sub-Category Product –Nodo final / hoja.", "description": "Producto en concreto para ser descargado o comprado por el usuario.", "width": "800" } 58 Posibles Representaciones Fija –Las categorías aparecen en plantilla y éstas se presentan mediante una tabla –Se necesitaría varias plantillas según la categoría InternetSoftwareCategories.JSP... STORE COMMUNICATIONS CONNECTIVITY Categories.type(“store”) Categories.type(“communications”) Categories.type(“connectivity”)... { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_58.jpg", "name": "Posibles Representaciones Fija –Las categorías aparecen en plantilla y éstas se presentan mediante una tabla –Se necesitaría varias plantillas según la categoría InternetSoftwareCategories.JSP...", "description": "STORE COMMUNICATIONS CONNECTIVITY Categories.type( store ) Categories.type( communications ) Categories.type( connectivity )....", "width": "800" } 59 Representación “Fija” Esta representación da más juego, al tener la información directa de cada celda en la tabla –Categoría => Objeto del Dominio Posibles cambios a realizar –Fuente, color, estilo –Conversión a lista de elementos –Cambio del orden de los elementos Cómo reconocer el cambio “Tabla => ComboBox” –Botón de conversión directa Primitiva Directa –Borrar Filas/Columnas/Tabla completa –Mover todos los elementos a una celda } Detección de Cambios Indirectos { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_59.jpg", "name": "Representación Fija Esta representación da más juego, al tener la información directa de cada celda en la tabla –Categoría => Objeto del Dominio Posibles cambios a realizar –Fuente, color, estilo –Conversión a lista de elementos –Cambio del orden de los elementos Cómo reconocer el cambio Tabla => ComboBox –Botón de conversión directa Primitiva Directa –Borrar Filas/Columnas/Tabla completa –Mover todos los elementos a una celda } Detección de Cambios Indirectos", "description": "Representación Fija Esta representación da más juego, al tener la información directa de cada celda en la tabla –Categoría => Objeto del Dominio Posibles cambios a realizar –Fuente, color, estilo –Conversión a lista de elementos –Cambio del orden de los elementos Cómo reconocer el cambio Tabla => ComboBox –Botón de conversión directa Primitiva Directa –Borrar Filas/Columnas/Tabla completa –Mover todos los elementos a una celda } Detección de Cambios Indirectos", "width": "800" } 60 Representación “Fija” (y II) En la detección de cambios indirectos se podría utilizar la idea del “asistente”, con un bajo nivel de intrusismo, definido mediante un Modelo de Diálogo apropiado –Esto disminuirá el porcentaje de ambigüedades que se pueden producir con cambios cuya inferencia resulta compleja para el sistema. –Se busca la interacción con el usuario –Conjunto de acciones pre-definidas (podrían ser Primitivas Directas) de antemano que pueden ser propuestas al usuario en un momento dado (idea del Asistente de Microsoft Office) Lo ideal sería que estás acciones se puedan sistematizar, borrando y añadiendo nuevas acciones, codificándolas de alguna forma (XML) y estableciendo alguna asociación entre acciones del usuario y acciones definidas. Esto podría ser útil al procesar el M. de Monitorización en busca de dichas acciones –Relacionado con ideas anteriores (metodología paso a paso o utilización de primitivas directas. filosofía de la Programación por Demostración) –¿En el Front-End o en el Back-End? => ¿Análisis del M. Monitorización?, ¿Edición asistida? Cómo llevar a cabo el cambio “Tabla => ComboBox” –Borrar las referencias a la relación y crear un combo u objeto especial para la selección de la categoría Creación de una clase/objeto pre-programado y lo suficientemente genérico para ser utilizado sobre otros objetos del dominio que contengan relaciones multivaluadas). Se podría definir en algún lenguaje tipo XML (como las reglas), de forma que sea variable y se pueda sistematizar su creación/utilización { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_60.jpg", "name": "Representación Fija (y II) En la detección de cambios indirectos se podría utilizar la idea del asistente , con un bajo nivel de intrusismo, definido mediante un Modelo de Diálogo apropiado –Esto disminuirá el porcentaje de ambigüedades que se pueden producir con cambios cuya inferencia resulta compleja para el sistema.", "description": "–Se busca la interacción con el usuario –Conjunto de acciones pre-definidas (podrían ser Primitivas Directas) de antemano que pueden ser propuestas al usuario en un momento dado (idea del Asistente de Microsoft Office) Lo ideal sería que estás acciones se puedan sistematizar, borrando y añadiendo nuevas acciones, codificándolas de alguna forma (XML) y estableciendo alguna asociación entre acciones del usuario y acciones definidas. Esto podría ser útil al procesar el M. de Monitorización en busca de dichas acciones –Relacionado con ideas anteriores (metodología paso a paso o utilización de primitivas directas. filosofía de la Programación por Demostración) –¿En el Front-End o en el Back-End. => ¿Análisis del M. Monitorización , ¿Edición asistida. Cómo llevar a cabo el cambio Tabla => ComboBox –Borrar las referencias a la relación y crear un combo u objeto especial para la selección de la categoría Creación de una clase/objeto pre-programado y lo suficientemente genérico para ser utilizado sobre otros objetos del dominio que contengan relaciones multivaluadas). Se podría definir en algún lenguaje tipo XML (como las reglas), de forma que sea variable y se pueda sistematizar su creación/utilización.", "width": "800" } 61 Posibles Representaciones Dinámica –Se utilizarán reglas/elementos dinámico para la generación de los datos –Menor número de plantillas, mayor generalidad... fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/> > >... fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/> > > Category.JSP { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/14/4390099/slides/slide_61.jpg", "name": "Posibles Representaciones Dinámica –Se utilizarán reglas/elementos dinámico para la generación de los datos –Menor número de plantillas, mayor generalidad...", "description": "fields = { name , contents } order-by = name orientation = horizontal /> > >... fields = { name , contents } order-by = name orientation = horizontal /> > > Category.JSP.", "width": "800" } 62 Representación “Dinámica” Aquí los cambios sobre la presentación afectarán a la Regla/Código dinámico en vez de afectar directamente a la plantilla JSP –El código HTML final a editar llevará la marca de la regla que lo generó:... Posibles cambios a realizar –Ordenación, profundidad, orientación –Cómo reconocer el cambio “Tabla => ComboBox” Igual que en el ejemplo anterior (3 transparencias más atrás) –Cómo llevar a cabo el cambio “Tabla => ComboBox” Considerar iniciativas del ejemplo anterior (2 transparencias más atrás) Aquí se podría borrar la Regla anterior, añadiendo una nueva regla que genere un ComboBox al encontrar la relación “Categories”, o también creando simplemente una nueva regla que cambiará la apariencia de lo generado a partir de la antigua Regla que ya existe –Aplicación recursiva de reglas Aunque no es conveniente crear demasiadas “redirecciones”, es mejor editar directamente el código dinámico o la Regla utilizando algunos de los métodos vistos en transparencias anteriores

11 Ejemplo de Uso 2 (II) Modelo de la Presentación Original 4) DESK modifica directamente el modelo de la Presentación, mediante el uso de instrucciones JAVA, para la implementación de condiciones sobre la visualización Modelo de la Presentación Modificado...... = 18) { %>...

12 Ejemplo de Uso 2 (y III) ProblemaProblema –¿Qué sucede si el texto seleccionado bajo DESK ya estaba bajo una condición sobre el Modelo de Usuario? Posible SoluciónPosible Solución –Que PEGASUS inserte meta-información codificada dentro de las etiquetas HTML generadas, de esta forma se podría localizar, bajo DESK, información administrativa relativa al texto sujeto a una condición texto Pre-Procesador de plantillas JSP para la generación de meta- información embebida en el HTML generado

13 Tratamiento de Reglas de Presentación

14 Generación de Documentos WEB en PEGASUS

15 Reglas de Presentación PEGASUS Gobiernan aspectos dinámicos relacionados con la renderización de los distintos objectos del dominio –Generación de enlaces –Correspondencia entre estilos de enlace y estados de objetos del dominio –Ordenación y disposición espacial de listas (de enlaces o fragmentos) –Generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Consisten en una lista de cero o más condiciones, seguidas por la presentación a aplicar cuando éstas se cumplen, descrita con la misma sintaxis de las plantillas La aplicación de las reglas es recursiva –Mayor generalidad en la renderización dinámica (respecto al caso de las modificaciones simples vistas anteriormente)

16 Reglas de Presentación PEGASUS Sin embargo, escribir reglas es una tarea delicada que requiere cierta familiaridad con el sistema –Aunque cualquier autor con conocimientos básicos de HTML podría “retocar” una regla Herramienta de Autor necesaria => DESK –DESK posee información de alto nivel sobre lo que el autor intenta hacer en el sistema Modelo de Monitorización –DESK incorpora funcionalidad para editar aspectos cercanos al propósito de las reglas Iteración sobre objetos / Listas de objetos del dominio Inserción de condiciones sobre distintos modelos Manejo de Listas y Tablas

17 Gestión de Reglas de Presentación con DESK La solución podría consistir en identificar qué acciones del usuario (modelo de monitorización) son susceptibles de ser aplicadas/convertidas a reglas Identificación de la acción pertinente –Generación de enlaces, correspondencia entre estilos de enlace y estados de objetos del dominio, ordenación y disposición espacial de listas (de enlaces o fragmentos), generación de presentaciones predefinidas para subconjuntos de la red semántica como árboles y listas encadenadas Búsqueda del contexto de la acción Inferencia de los cambios sobre la “fuente” –M. Dominio, M. Presentación (Plantillas JSP + Reglas de Presentación)

18 Gestión interna de Reglas en PEGASUS Fichero XML Un sub-modelo más en PEGASUS –Modelo del Dominio / Ontología del Dominio –Modelo del Usuario –Modelo de la Presentación Plantillas JSP (Templates) Sub-modelo de Reglas de Presentación El árbol JDOM se guardará en memoria –Se “cargará” junto con el resto de modelos Fichero Init.jsp Fichero Transact.jsp La ejecución y aplicación de las reglas dependerá del “Runtime” PEGASUS

19 Gestión interna de Reglas en PEGASUS HTML XML ++ Monitoring Model + Context Model Changes Management DESK Server-Side PEGASUS Runtime System Domain Model Presentation Model User Model HTML Monitoring Model Finding out Context DESK Front-End XML Authorized User (Enriched Monitoring Model) Ahora, Modelo de la Presentación => Plantillas +Reglas Presentation Rules ? JSP Templates

20 Uso de Reglas, pautas generales Necesaria una estructura general para definirlas –Matching => Representa a partir de qué Objeto del Dominio se va a buscar una similitud –Ámbito de Aplicación => Para identificar estados especiales sobre los Objetos del Dominio a modificar –Condición de Aplicación => Selecciona qué Objetos del “Matching” serán alterados con la nueva presentación a aplicar –Nueva Presentación a Aplicar => Nuevas etiquetas para modificar la presentación sobre el Objeto del Dominio Rule { Matching {...} Ámbito de Aplicación {...} Condición de Aplicación {...} Nueva Presentación a Aplicar {...} }

21 Uso de Reglas, pautas generales (y II) Estado “inicial” de la presentación –Estado por defecto, se ejecutará y se guardará antes de que cualquier regla cambie el “estado” de la presentación (Ejemplo: prerequisites.tree() ) –Generado por HADES. Módulo de creación de los modelos por defecto (Modelo de la Presentación) Se creará un protocolo, a partir de métodos, para alterar el estado de la visualización –Métodos bien definidos, construidos homogéneamente. –La “renderización” podrá alterarse a partir del paso de mensajes entre objetos del dominio prerequisites.tree(“Horizontal”) prerequisites.tree(“Vertical”)

22 Ejemplos de Uso Ejemplo 1 –Modificación de los colores de los links “ya utilizados” por el usuario en la presentación Ejemplo 2 –El usuario decide cambiar la forma de ver los links HTML para transformarlos en una lista ordenada de links

23 Ejemplo de Uso 1 1) El usuario, bajo DESK, selecciona un link “ya utilizado” de una lista para cambiar el color de dicho link 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End)

24 Ejemplo de Uso 1 (II) Regla de Presentación Original 4) DESK Infiere conocimiento que le permite decidir el modificar directamente la Regla de Presentación para la implementación de condiciones sobre la visualización de los links “ya usados” para la lista de pre-requisitos Regla de Presentación Modificada

25 Ejemplo de Uso 1 (III) ProblemaProblema –No está clara la localización del contexto “prerequisites” a partir de un “item” seleccionado bajo DESK Posible Solución IPosible Solución I –Utilizar meta-información embebida en HTML y generada por PEGASUS mediante un pre-procesamiento de las plantillas de presentación, o dejando esta carga a los métodos de los Objetos del Dominio, responsables de su propia generación de código HTML –¿Sobraría la localización posterior de contexto (Back-End) ? => Quizás sobraría para este tipo de casos / relaciones complejas... Plantilla JSP Página HTML generada Pre-Procesamiento

26 Ejemplo de Uso 1 (y IV) Posible Solución IIPosible Solución II –Realizar “matching” con la parte “Presentation” de las Reglas, hasta encontrar exactamente cual es la regla que se pretende cambiar. Esta solución es más directa y además ayudaría a localizar mucho mejor la regla que se prende cambiar. Ejemplo:

27 Ejemplo de Uso 2 1) El usuario, bajo DESK, selecciona un conjunto de links HTML para crear una lista 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End)

28 Ejemplo de Uso 2 (II) 4) DESK Infiere conocimiento que le permite decidir el modificar directamente el sub-modelo de Reglas de Presentación para crear una nueva regla que afecte a la visualización de los links para la lista de pre-requisitos Nueva Regla de Presentación

29 Ejemplo de Uso 2 (y III) ComentariosComentarios –Este tipo de ejemplo, donde entra en juego la generación de una nueva regla, no es factible de momento Creación de reglas => solución poco general => para resolver siempre los mismos casos => Habría que generalizar y “factorizar” con respecto a reglas ya creadas Es posible que no se disponga de suficiente información para generar reglas en tiempo real Para justificar la creación de nuevas reglas sería necesaria la intervención de, por ejemplo, el Modelo de Usuario, para poder crear reglas de ámbito y funcionalidad más generales –La forma de hacer esto bajo DESK no sería demasiado WYSIWYG

30 Tratamiento de la Batería de Reglas Agosto 2002

31 Análisis Previo ¿Cómo puede DESK inferir cambios en las Reglas de Presentación a partir de cambios que usuario realiza en la presentación? –Mediante la utilización de Primitivas Directas Permite un control más preciso sobre lo que el usuario puede hacer El mecanismo de inferencia es más directo y menos ambiguo Mayor comodidad para el usuario sobre todo si este es poco experto (DESK lo hace todo con una sola acción) Se pierte naturalidad al acercarse más al sistema Pregunta filosófica: ¿Merece la pena hacer Programación. Por Demostración?: Depende, quizás algunas veces si, aunque no hay que dejarlo todo en manos de un motor de inferencia –Mediante la detección de cambios indirectos (en varios pasos) que afectarán (en su totalidad) a alguna Regla de Presentación Necesario interpretar y analizar el Modelo de Monitorización Se eleva el número de ambigüedades que se pueden producir Esta opción es bastante interesante de cara a la Program. por Demostración

32 Análisis Previo (II) ¿Todas las reglas son susceptibles de ser modificadas? –Elaborar un conjunto de primitivas lo suficientemente amplio que recojan las distintas correspondencias entre el cambio llevado a cabo por el usuario y tipo de Regla a modificar –Estructuras más susceptibles de ser aplicadas/generadas por reglas Listas de Elementos (Enumeraciones) (Grafos, Árboles) Tablas Estilos de los links Widgets (inputs, botones...)

33 Análisis Previo (III) Problema –La mayoría de las reglas hacen referencia a relaciones complejas entre objetos ( prerequisites, courses, etc.) que son difíciles de ser detectadas a partir del la edición en DESK, incluso en el Back-End, utilizando la información de los modelos existentes Solución –Utilizar un pre-procesamiento, en PEGASUS, a la hora de generar el código HTML a partir de las Reglas o los métodos de objetos de alto nivel ( prerequisites.tree(“Horizontal”) )

34 Análisis Previo (IV) Regla 1... Regla N Reglas de Presentación Plantilla i Plantillas JSP Meta Información Etiquetas HTML Pre-Procesamiento Documento HTML Final Modelo de la Presentación Pre-procesamiento del documento HTML antes de ser enviado Al usuario final - Dependerá de PEGASUS - Sobre-escritura del “Writer” JSP PEGASUS

35 Análisis Previo (V) ¿Qué tipo de meta-información sería útil añadir al HTML Final? –Datos sobre estructuras especiales generadas dinámicamente y cuyo reconocimiento no sea obvio con la información disponible en DESK Listas y Tablas de Elementos generadas a partir de Relaciones Multivaluadas ¿Dónde debería ir codificada esa información? –Como atributos de dichas estructuras (Tablas, Listas), éstos atributos pueden ser reconocidos perfectamente por DESK –Pensar en una extensión del HTML, que es perfectamente “browseable”, con nombre propio, y detallar su DTD ¿Qué codificaría dicha información? –Datos de alto nivel cuya obtención no resulte trivial a partir de los distintos modelos PEGASUS Nombre de la Relación Multivaluada Código de Regla a partir de la cual ha sido generado el fragmento HTML Otros datos, dependiendo de la fuente que generó dicho fragmento HTML –Condiciones sobre el modelo de Usuario u otros modelos existentes –Número de ítems afectados en la evaluación de la Regla –Etc.

36 Análisis Previo (VI) Por Ejemplo, el siguiente código en plantilla JSP: prerequisites.tree(“Vertical”) Podría generar el siguiente HTML Final:

37 Análisis Previo (VII) 1) El usuario, bajo DESK, selecciona el texto de una lista para cambiar la disposición de los elementos, de vertical a horizontal 2) DESK crea una entrada en el Modelo de Monitorización reflejando la acción (Front-End)

38 Análisis Previo (VIII) Modelo de la Presentación Original 3) DESK modifica directamente el modelo de la Presentación, mediante el uso del protocolo de paso de mensajes entre objetos del dominio (Back-End) Modelo de la Presentación Modificado.........

39 Análisis Previo (y IX) Esta misma filosofía podría ser aplicada a las Reglas –Codificándolas (o que lo haga PEGASUS internamente): –Para luego poder ser identificadas en DESK: –Esto Permitiría el encontrar, de una forma mucho más directa, la regla que se desea cambiar, sin necesidad de hacer “matching” en la parte de Presentación de la Regla (solución propuesta en la transparencia 26)

40 Reglas de Generación de Tablas y Listas Generan Tablas y Listas a partir de la iteración sobre elementos de una Relación Multivaluada Se pueden tratar siempre y cuando se genere meta-información adicional sobre ellas (id, tipo, relación afectada, cobertura,...) Las que vienen modelizadas a un nivel de especificación mayor son las más susceptibles de ser tratadas, y son las que pueden dar más juego a la hora de modificar distintos campos de las mismas. –Iteración directa sobre campos ( course.year... ) => nº de campo –Especificación directa en la creación ( makeTable, makeTree ) Al contrario que las otras, donde los cambios serían más globales (,... ) al menos que no estén lo suficientemente parametrizados

41 Ejemplo Número 1 Course name Year Teacher Room Schedule > Course name Year Teacher Room Schedule OOP 2001-2002 P. Castells A-201 1.- Introduction 2.-... Operating Systems I 2001-2002 J. A. Macías A-202 1.- Introduction 2.-...... ReglaPosible Código Generado (HTML Final) Podría incluso guardarse el nombre de la variable sobre la que se itera: var_name = “course” Este tipo de “Reglas” podrían ir directamente en la plantilla JSP

42 Ejemplo Número 1 (y II) Tratamiento bajo DESK (A partir del HTML Final) –El usuario hace un cambio sobre la tabla (por ejemplo: cambiar el color del año de los cursos) DESK Fron-End sabe que la tabla ha sido generada a partir de una Regla (R01), además la Relación Multivaluada es identificada igualmente (courses) En este caso, saber el Atributo modificado es fácil, solamente hay que saber qué columna es la que se ha modificado (nº 2 => year). La fila puede indicar si se trata de los títulos o de la inf. dinámica –En el caso de que la variable de iteración se corresponda con el nombre del objeto, DESK Back-End podría buscar el contexto del cambio y encontrará el Atributo “year” del Objeto “course” DESK busca en la Regla R01, la iteración sobre “courses” y en concreto el Atributo “course.year”, añadiendo la modificación deseada:......

43 Ejemplo Número 2 > > > > > Reglas Creación Genérica De Tablas de forma Vertical y Horizontal Este tipo de “Reglas” podrían ir directamente en la plantilla JSP

44 Ejemplo Número 2 (y II) Este tipo de Regla da menos juego a la hora de realizar cambios bajo DESK –Especificación demasiado genérica –No existen “campos” o Atributos “tangibles” Poco juego a la hora de manipular e inferir qué datos son los que han cambiado partiendo del HTML final en DESK Posible Solución / Mejora –Añadir más meta-información sobre lo generado (codif. campos) –Mayor parametrización en la parte de la Regla Esto puede dar más juego a la hora de realizar cambios mediante el protocolo de paso de mensajes (alteración del estado/funcionalidad) Cambios Posibles desde DESK –Conversión Tabla Vertical => Tabla Horizontal => Lista Siempre y cuando el aspecto de la regla sea “fijo”, se podrían tener patrones de este tipo de reglas para una conversión en el Layout

45 Ejemplo Número 3 fields = {"name","year","credits","contents"} order-by = "year" orientation = "vertical"/> fields = {"name","students"{"name","address"{"street","city","zipCode"}}}/> Reglas Este otro tipo de Reglas pueden dar bastante juego a la hora de cambiar el orden y la forma de creación de los elementos, debido al alto nivel de especificación con el que han sido definidas. La del Ejemplo número 1 también, pero quizás sería algo más costoso. Si la sintaxis fuera más flexible, incluso se podrían realizar cambios en el estilo (color, fuente, etc.) de los ítems Este tipo de “Reglas” podrían ir directamente en la plantilla JSP, y suelen preceder a las vistas anteriormente (definen los campos sobre los que iterar)

46 Ejemplo Número 3 (y II) Realizar este tipo de cambios sería tan fácil como detectarlos a nivel de edición (drag-drop), codificando el cambio: (Name Year) Lo que modificaría directamente la regla en cuestión: –Otros cambios: Ordenación, Orientación, Profundidad...

47 Ejemplo Número 4 15"/> fields()"/> 5"/>... Reglas Reglas sujetas a condiciones sobre la visualización de ciertos datos, en forma de lista o tabla

48 Ejemplo Número 4 (II) Se comentaron el el apartado de “Análisis Previo” La forma de identificarlas es mediante la generación de meta- información apropiada, de forma que puedan ser identificadas bajo DESK e inferir su cambio posteriormente –Código y Tipo de Regla –Relación Multivaluada –Nombre de la Clase Los cambios sobre estas Reglas pueden venir dados en forma de primitivas que permitan –Cambiar el layout (“ vertical ”, “ horizontal ”, “ asTable ”...) –Cambiar el contenido (“ this.map(“title”) ”) –Cambiar algunas de las condiciones de activación / visualización ( length(), orientation... ) Quizás esto requeriría de una “edición avanzada” => Por ejemplo: el usuario introduce una línea más y DESK infiere que se pretende cambiar (dentro del código afectado por la regla) la condición de activación de la regla ( length()>N+1 ) Esto quizás es solamente útil para casos de generación directa: prerequisistes.tree(“Vertical”) }

49 Ejemplo Número 4 (III) 1) El usuario, bajo DESK, selecciona un link “ya utilizado” de una lista para cambiar el color de dicho link 2) La Lista ha sido generada a partir de la Regla con ID = R10, DESK lo detecta y crea una entrada en el Modelo de Monitorización

50 Ejemplo Número 4 (y IV) Regla de Presentación Original 4) DESK Back-End utiliza el conocimiento disponible en el Modelo de Monitorización, el cual le permite decidir el modificar directamente la Regla de Presentación, para cambiar el color de los links “ya usados” (Asociación: Change_Color => cambio en ) Regla de Presentación Modificada

51 Ampliaciones / Conclusiones ¿Por qué no utilizar siempre meta-información en vez de buscar en el Modelo del Dominio? –Justificación El basar la búsqueda en Meta-Información hace el proceso de inferencia más lento en el Cliente (Front-End), siendo además más complejo y tedioso (sería necesario localizar las etiquetas con algoritmos de búsqueda de contexto) Esto no se pensó así desde el principio, por eso podría funcionar de las dos formas (poniendo meta-información y sin ponerla y buscándola DESK). Una nueva versión de PEGASUS debería pues generar la meta-información El colocar meta-información también ayuda a localizar inserciones-borrados en DESK, para luego poderlos trasladar a la plantilla (ahora se sabe qué objeto ha generado cada párrafo y es fácil situar los cambios) Para reglas, se podría utilizar un “tag” más genérico:, en vez de añadir atributos. Esto es bastante útil si la generación de una misma regla engloba a varios bloques (varias tablas, literales-cadenas y listas) –Quizás, en resumen, sería conveniente utilizar Meta-Información exclusivamente para el tratamiento de Reglas de Presentación

52 Ampliaciones/Conclusiones (II) –Problemas 1. El usuario podría, mediante DESK, editar (insertar elementos, cadenas...) entre, por ejemplo, la etiqueta de contexto de la Regla y la definición de una tabla, o entre cualquiera de los elementos que engloban el bloque 2. ¿Qué pasa si convertimos una lista de elementos a una colección de párrafos (no-lista)? –Podría perderse la información sobre Regla que generó el bloque –Posibles Soluciones: 1. Para ciertos cambios sobre reglas, no importa demasiado que el usuario añada un EOL o una nueva línea dentro de un bloque-regla –Pues se buscan acciones y datos muy concretos (ID-Regla, Primitiva de Cambio (color, intercambio de elementos, alteración del orden o del layout)) –En cualquier caso, cada elemento dentro de podría llevar el código de Regla (o subcódigo) y el orden de aparición, para evitar perder la secuencia si un usuario introduce ítems “extraños” dentro 2. No importa que los elementos pierdan la estructura, siempre que se siga conservando el o los atributos (aunque haya que crear un párrafo para la persistencia de los atributos)

53 Ampliaciones/Conclusiones (III) Intentar llegar a un “consenso” para modelizar las acciones que llevan a cabo las reglas –De esta forma se podrían crear primitivas asociadas a cada acción –Protocolo coherente ( change_color, change_orientation_to_vertical,...) Los elementos de una lista se puedan re-ordenar a partir de criterios establecidos en una regla –El usuario podría hacerlo desde DESK, mediante un algoritmos de ordenación de cadenas a partir de un criterio dado. –Es interesante decir que DESK diferencia qué tipo de acción se está dando e infiere información distinta dependiendo de la precedencia de la estructura (Regla, lista genérica definida por el usuario, tabla,...) Enumerar qué tipos/casos de acciones se pueden realizar sobre listas/tablas

54 Ampliaciones/Conclusiones (IV) Se podría crear un módulo de edición interactivo de Reglas –Por ejemplo: el usuario hace “doble click” sobre un fragmento generado a partir de una Regla, seguidamente aparece una ventana para cambiar las propiedades de generación / activación de la Regla Esto implicaría una modelización uniforme de las Reglas para que puedan ser tratadas homogéneamente –Este caso es parecido al de la creación de condiciones sobre el Modelo del Usuario y de la Plataforma (visto anteriormente) Sería necesario disponer del Modelo de Reglas en el Front-End Posible pérdida del WYSIWYG en la edición

55 Ampliaciones/Conclusiones (V) En general, se podrían englobar las acciones no WYSIWYG relacionadas con la edición abstracta basada en modelos –Tipos: Modelado del Usuario y de la Plataforma Edición y modificación directa del Sub-Modelo de Reglas Cambios a partir de la Edición directa sobre otros modelos –Utilizando acceso directo a los modelos o, quizás, añadiendo Meta-Información sobre los mismos para realizar posteriormente los cambios en el Back-End

56 Ejemplo Práctico Septiembre - 2002

57 Caso a Estudiar Página WEB de Tucows, con distinto tipo de Software para Internet Categoría principal: Internet –Distintas categorías y sub- categorías –Posible Ontología: En forma de árbol Flap / Category / Sub-Category Product –Nodo final / hoja. Producto en concreto para ser descargado o comprado por el usuario

58 Posibles Representaciones Fija –Las categorías aparecen en plantilla y éstas se presentan mediante una tabla –Se necesitaría varias plantillas según la categoría InternetSoftwareCategories.JSP... STORE COMMUNICATIONS CONNECTIVITY Categories.type(“store”) Categories.type(“communications”) Categories.type(“connectivity”)...

59 Representación “Fija” Esta representación da más juego, al tener la información directa de cada celda en la tabla –Categoría => Objeto del Dominio Posibles cambios a realizar –Fuente, color, estilo –Conversión a lista de elementos –Cambio del orden de los elementos Cómo reconocer el cambio “Tabla => ComboBox” –Botón de conversión directa Primitiva Directa –Borrar Filas/Columnas/Tabla completa –Mover todos los elementos a una celda } Detección de Cambios Indirectos

60 Representación “Fija” (y II) En la detección de cambios indirectos se podría utilizar la idea del “asistente”, con un bajo nivel de intrusismo, definido mediante un Modelo de Diálogo apropiado –Esto disminuirá el porcentaje de ambigüedades que se pueden producir con cambios cuya inferencia resulta compleja para el sistema. –Se busca la interacción con el usuario –Conjunto de acciones pre-definidas (podrían ser Primitivas Directas) de antemano que pueden ser propuestas al usuario en un momento dado (idea del Asistente de Microsoft Office) Lo ideal sería que estás acciones se puedan sistematizar, borrando y añadiendo nuevas acciones, codificándolas de alguna forma (XML) y estableciendo alguna asociación entre acciones del usuario y acciones definidas. Esto podría ser útil al procesar el M. de Monitorización en busca de dichas acciones –Relacionado con ideas anteriores (metodología paso a paso o utilización de primitivas directas. filosofía de la Programación por Demostración) –¿En el Front-End o en el Back-End? => ¿Análisis del M. Monitorización?, ¿Edición asistida? Cómo llevar a cabo el cambio “Tabla => ComboBox” –Borrar las referencias a la relación y crear un combo u objeto especial para la selección de la categoría Creación de una clase/objeto pre-programado y lo suficientemente genérico para ser utilizado sobre otros objetos del dominio que contengan relaciones multivaluadas). Se podría definir en algún lenguaje tipo XML (como las reglas), de forma que sea variable y se pueda sistematizar su creación/utilización

61 Posibles Representaciones Dinámica –Se utilizarán reglas/elementos dinámico para la generación de los datos –Menor número de plantillas, mayor generalidad... fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/> > >... fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/> > > Category.JSP

62 Representación “Dinámica” Aquí los cambios sobre la presentación afectarán a la Regla/Código dinámico en vez de afectar directamente a la plantilla JSP –El código HTML final a editar llevará la marca de la regla que lo generó:... Posibles cambios a realizar –Ordenación, profundidad, orientación –Cómo reconocer el cambio “Tabla => ComboBox” Igual que en el ejemplo anterior (3 transparencias más atrás) –Cómo llevar a cabo el cambio “Tabla => ComboBox” Considerar iniciativas del ejemplo anterior (2 transparencias más atrás) Aquí se podría borrar la Regla anterior, añadiendo una nueva regla que genere un ComboBox al encontrar la relación “Categories”, o también creando simplemente una nueva regla que cambiará la apariencia de lo generado a partir de la antigua Regla que ya existe –Aplicación recursiva de reglas Aunque no es conveniente crear demasiadas “redirecciones”, es mejor editar directamente el código dinámico o la Regla utilizando algunos de los métodos vistos en transparencias anteriores