desk 3.0 tratamiento automático, mediante desk, de aspectos dinámicos relativos a la...

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

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:

<%= JAVA-Expression %>

– Ejecución de métodos sobre Objetos del Dominio:

<%= prerequisites.tree() %>

2) Manipulación y Tratamiento de Reglas de Presentación mediante DESK

Cambios simples sobre la generación dinámica de HTML

a través de código JAVA

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

• 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

• 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”)



• 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)

Ejemplo de Uso 11) El usuario, bajo DESK, selecciona el textode una lista para cambiar la disposición de los elementos, de vertical a horizontal

2) DESK crea una entrada en el Modelo deMonitorización reflejando la acción (Front-End)

<Modify_List ID=“LIST21” <Item_List action=“Change to Horizontal”> <Item_01> ... </Item_01> <Item_02> ... </Item_02> </Item_List> ...

</Modify_List>

3) DESK Localiza el Contexto (Back-End)

<Context> <Found_In> <Class class_name=”Algorithm" relation_name=“prerequisites” ... </Found_In></Context>

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

...<% prerequisites.tree(“Vertical”) %>...

...<% prerequisites.tree(“Horizontal”) %>...

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

Ejemplo de Uso 21) El usuario, bajo DESK, selecciona un textoque se desea visualizar solamente si el usuario es mayor de edad


<Condition ID=“Cond1” <Text_Affected> DIJKSTRA (G, s)<br>INICIALIZAR (G, s)<br>Q = V[G]<br>while Q not empty do<br> u = EXTRACT_MIN (Q)<br>for v in Ady[u] do<br>RELAX (G, u, v) </Text_Affected> <Condition> user.age>=18 </Condition> ...

</Condition>


<Context> <Found_In> <Class class_name=”Algorithm" relation_name=“Procedure” ... </Context>



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


...<%= procedure %>...

...

<% if (user.age >= 18) { %> <%= procedure %> <% } %>...

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

<P under_condition=“user.age=18” >

texto

</P>

• Pre-Procesador de plantillas JSP para la generación de meta-información embebida en el HTML generado

Tratamiento de Reglas de Presentación

Generación de Documentos WEB en PEGASUS

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)

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

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)

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

Gestión interna de Reglas en PEGASUS

HTML

XML++

Monitoring Model+

Context Model

Changes Management

DESK Server-Side

PEGASUSRuntime System

Domain Model

Presentation Model

User ModelHTML

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

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 {...}}

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”)

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

Ejemplo de Uso 11) El usuario, bajo DESK, selecciona un link“ya utilizado” de una lista para cambiar el color de dicho link


<Modify_List_Item ID=“LIST21” <Action=“Change Color” value=“#007700”/> <Item_01 status=“visited”> ... </item_01>...

</Modify_List_Item>




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ónde los links “ya usados” para la lista de pre-requisitos

Regla de Presentación Modificada

<Rule class="DomainObject"> <test condition="asLink && read"/> <test-every var="item" list="prerequisites" condition="item.known"/> <presentation> <font color="#006600"> <%= this %> </font> </presentation></Rule>

<Rule class="DomainObject"> <test condition="asLink && read"/> <test-every var="item" list="prerequisites" condition="item.known"/> <presentation> <font color="#007700"> <%= this %> </font> </presentation></Rule>

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

<%= prerequisites.tree(“Vertical”) %>

<UL relation_id=“prerequisites”> <LI id=“item1”> ... </LI> ... </UL>

Plantilla JSP Página HTML generadaPre-Procesamiento

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:

<font color=“#00660” <a href=“...”> Relaxation Method </a></font>

Puede Hacer Matching con la partede “Presentation” de la regla anterior:

<font color=“#00660” <%= this %></font>

Información sobre uno de los Prerequisitos que se ha generado dinámicamente en HTML. El usuario selecciona esta información utilizando DESK (paso número 1)

Se podría pensar en codificar esta parte de una formaun tanto más estructurada para que el “matching” resulte más cómodo de realizar => Usar codificación XML

Ejemplo de Uso 21) El usuario, bajo DESK, selecciona un conjunto de links HTML para crear una lista


<Create_List ID=“LIST22” <Text_Affected> ... </Text_Affected> <Item_List type=“HTML Links” <Item_01 status=“visited”>...</Item_01> ... </Item_List> ...

</Modify_List_Item>




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

<Rule class="List[DomainObject]"> <test-every var="item" list=”prerequisites" condition="item.asLink"/> <presentation> <ul> <iterate var="item" list="this"> <li> <%= item %> </li> </iterate> </ul> </presentation></Rule>

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

Tratamiento de la Batería de Reglas

Agosto 2002

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

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

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”))

Análisis Previo (IV)

Regla 1 ... Regla N

Reglas de Presentación

Plantillai

Plantillas JSP

Meta Información Etiquetas HTML

Pre-Procesamiento

DocumentoHTMLFinal

Modelo de la Presentación

Pre-procesamiento del documento HTML antes de ser enviadoAl usuario final

- Dependerá de PEGASUS- Sobre-escritura del “Writer” JSP

PEGASUS

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.

Análisis Previo (VI)

• Por Ejemplo, el siguiente código en plantilla JSP:

prerequisites.tree(“Vertical”)

• Podría generar el siguiente HTML Final:

<UL relation_name=“prerequisites” class_name=“Algorithm” <LI> Relaxation Method </LI> <LI> ... </LI> ...</UL> >

Análisis Previo (VII)

1) El usuario, bajo DESK, selecciona el textode una lista para cambiar la disposición de los elementos, de vertical a horizontal


<Modify_List ID=“LIST21” <Local_Context class_name=“Algorithm” relation_name=“prerequisites”/> <Item_List action=“Change to Horizontal”> <Item_01> ... </Item_01> <Item_02> ... </Item_02> ... </Item_List>

</Modify_List>

Un usuario, utilizando DESK, podría cambiar la disposición de los ítems como sigue:

En este caso el contexto se localiza localmente, así se aprovecha la meta-información generada en PEGASUS para el objeto “prerequisites”

Análisis Previo (VIII)


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)


...<% prerequisites.tree(“Vertical”) %>...

...<% prerequisites.tree(“Horizontal”) %>...

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)

<Rule [ID=“R01”] class="DomainObject”> <test-every list="prerequisites”> ...</Rule>

<UL rule_id=“R01” relation_name=”prerequisites”> <LI> Relaxation Method </LI> <LI> ... </LI> ...</UL>

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 (<%= field >, <%= item %>...) al menos que no estén lo suficientemente parametrizados

Ejemplo Número 1

<table> <tr> <td> Course name </td> <td> Year </td> <td> Teacher </td> <td> Room </td> <td> Schedule </td> </tr> <iteration var = "course" list = <%= courses %>> <tr> <td> <%= course.name > </td> <td> <%= course.year > </td> <td> <%= course.teacher > </td> <td> <%= course.room > </td> <td> <%= course.schedule > </td> </tr> </iteration></table>

<table rule_id=“R01” relation_name=“courses”> <tr> <td> Course name </td> <td> Year </td> <td> Teacher </td> <td> Room </td> <td> Schedule </td> </tr> <tr> <td> OOP </td> <td> 2001-2002 </td> <td> P. Castells </td> <td> A-201 </td> <td> 1.- Introduction 2.- ... </td> </tr> <tr> <td> Operating Systems I </td> <td> 2001-2002 </td> <td> J. A. Macías </td> <td> A-202 </td> <td> 1.- Introduction 2.- ... </td> </tr> ...</table>

Regla Posible Código Generado (HTML Final)

Podría incluso guardarse el nombrede la variable sobre la que se itera:

var_name = “course”

Este tipo de “Reglas” podríanir directamente en la plantilla JSP

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:

...<td> <font color=“#00660” <%= course.year > </font> </td>...

Ejemplo Número 2

<table> <tr> <iteration var = "field" list = <%= fields %>> <td> <%= field %> </td> </iteration> </tr> <iteration var = "item" list = <%= list %>> <tr> <iteration var = "field" list = <%= fields %>> <td> <getProperty <%= item %> <%= field %>> </td> </iteration> </tr> </iteration></table>

<table> <iteration var = "field" list = <%= fields %>> <tr> <td> <%= field %> </td> <iteration var = "item" list = <%= list %>> <td> <getProperty <%= item %> <%= field %>> </td> </iteration> </tr> </iteration></table>

ReglasCreación GenéricaDe Tablas de formaVertical y Horizontal

Este tipo de “Reglas” podrían

ir directamente en la plantilla JSP

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

Ejemplo Número 3

<makeTable records = <%= courses %> fields = {"name","year","credits","contents"} order-by = "year" orientation = "vertical"/>

<makeTree relation = "prerequisites" levels = 3/>

<makeTree list = <%= courses %> 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 precedera las vistas anteriormente (definen los campos sobre los que iterar)

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

<Modify_Table ID=“TAB21” <Local_Context rule_id=“R01”

rule_type=“make_table” relation_name=“courses”/> <Action type=“interchange” from=“1” to=“2”> <Item_01> ... </Item_01> <Item_02> ... </Item_02> </Action></Modify_Table>

<makeTable records = <%= courses %> fields = {”year",”name","credits","contents"} order-by = "year" orientation = "vertical"/>

Ejemplo Número 4

<Rule class="List[DomainObject]"> <test condition="asTable"/> <test condition="orientation == undefined"/> <test condition="length() > 15"/> <test condition="length() > fields()"/> <presentation> <%= this.orientation ("vertical") %> </presentation></Rule>

<Rule class="List[DomainObject]"> <test-every condition="small"/> <test condition="length() > 5"/> <presentation> <%= this.asTable() .orientation("horizontal") %> </presentation></Rule>

...

Reglas

Reglas sujetas a condicionessobre la visualización de ciertos datos, en forma delista o tabla

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”)}

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

<Modify_List_Item ID=“LIST21” <Local_Context rule_id=“R10” relation_name=“prerequisistes” <Action=“change_color” value=“#007700”/> <Item_01 status=“visited”> ... </item_01>

</Modify_List_Item>

<Rule ID=“R10” class="DomainObject"> <test condition="asLink () && read ()"/> <test-every var="item" list="prerequisites" condition="item.known ()"/> <presentation> <font color="#006600"> <%= this %> </font> </presentation></Rule>

(¿ Modify_Rule ?O

¿Modify_List_Item ?,¿List_ID?)

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 <font color=“#NNN”>)

Regla de Presentación Modificada

<Rule ID=“R10” class="DomainObject"> <test condition="asLink && read"/> <test-every var="item" list="prerequisites" condition="item.known"/> <presentation> <font color="#006600"> <%= this %> </font> </presentation></Rule>

<Rule ID=“R10” class="DomainObject"> <test condition="asLink && read"/> <test-every var="item" list="prerequisites" condition="item.known"/> <presentation> <font color="#007700"> <%= this %> </font> </presentation></Rule>

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: <Presentation_Rule ID=“R25”>, 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

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 <Presentation_Rule> 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 <Presentation_Rule> o los atributos (aunque haya que crear un párrafo <P> para la persistencia de los atributos)

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

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

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

Ejemplo Práctico

Septiembre - 2002

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

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

<%= Title %><%= Flaps %><%= SearchCombo %>...

<table> <tr> <td> STORE </td> <td> COMMUNICATIONS </td> <td> CONNECTIVITY </td></tr> <tr> <td> Categories.type(“store”) </td> <td> Categories.type(“communications”) </td> <td> Categories.type(“connectivity”) </td></tr> ...</table>

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

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

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

<%= Title %><%= Flaps %><%= SearchCombo %>...<makeTable records = <%= Categories %> fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/><table> <iteration var = "field" list = <%= fields %>> <tr> <td> <%= field %> </td> <iteration var = "item" list = <%= list %>> <td> <getProperty <%= item %> <%= field %>> </td> </iteration> </tr> </iteration></table>

<%= Title %><%= Flaps %><%= SearchCombo %>...<makeTable records = <%= Categories %> fields = {”name","contents"} order-by = ”name" orientation = ”horizontal"/><table> <iteration var = "field" list = <%= fields %>> <tr> <td> <%= field %> </td> <iteration var = "item" list = <%= list %>> <td> <getProperty <%= item %> <%= field %>> </td> </iteration> </tr> </iteration></table>

Category.JSP

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ó:

<table rule_id=“R01”>

...

• 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

desk 3.0 tratamiento automático, mediante desk, de aspectos dinámicos relativos a la...

Documents