Componentes personalizados en Echo2 – Parte III

21/11/2006

Desarrollo con Echo2
Este es el tercero de una serie de artículos acerca de la creación de componentes para Echo2:

En los anteriores artículos vimos cómo crear ocmponentes personalizados para Echo2 con sus propios elementos de representación y código de lado cliente. Esto se realizó completamente dentro del contexto de Echo2 y el modelo de programación Java del lado del servidor.

Sin embargo existe un inconveniente en esta método, la productividad de desarrollo, y especialmente temas relacionados con la depuración del JavaScript del lado del cliente. Este artículo trata una nuevo modo de desarrollo de un nuevo componentes personalizado que permite una sesión de desarrollo muy productiva y componentes bien depurados, cuyo resultado se pude utilizar dentro del framework Echo2.

Explicación del Problema de la Productividad

La depuración JavaScript de un componente personalizado puede llevar hasta el 50% del tiempo de desarrollo. Es relativamente sencillo inventar propiedades del componente, crear una representación XHTML y diseñar los mensajes XML para el códiog del lado cliente, sin embargo es más difícil asegurarse de que el JavaScript funciona como es debido.

Echo2 tiene un mecanismo para asegurarse de que solamente se descarga el JavaScript necesario para un componente. Esto hace que una aplicación web Echo2 sea solamente tan grande como necesite ser.

Esto lo consigue enviando el JavaScript necesario en mensajes AJAX y evaluando dinámicamente el código. Es posible que te preguntes porqué no, sencillamente, crea dinámicamente elementos script XHTML y utiliza el código JavaScript en cuestion. El problema es que algunos navegadores, como Safari, no permiten esto y por tanto la evaluación dinámica era la mejor solución multinavegador.

Por otro lado, lo malo es que los depuradores JavaScript existentes, Venkman, IE Script Debugger y FireBug, tienen problemas en ver este código JavaScript y por tanto es muy difícil poner puntos de interrupción donde quieres y hace que el ciclo de depuración sea más difícil de lo que debería.

De alguna manera esto se puede subsanar escribiendo sentencias debugger; en el código fuente pero esto requiere cambios en el código fuente simplemente para poner un punto de interrupción.

Además debes reiniciar tu servidor de aplicaciones para que cualquier cambio en el JavaScript tenga efecto.

El uso de evaluar dinámicamente el JavaScript descargado hace que nuestro código tenga que escribirse de un modo determinado.

Por ejemplo funciones como esta:

function fred () {
alert(‘fred called’);
}

deben escribirse como

fred = funcion() {
alert(‘fred called’);
};

El Método – Prototipado Estático

La idea básica es que desarrollaremos el 90% del código JavaScript y XHTML fuera del framework Echo2, lo haremos funcionar usando simples archivo XHTML y JavaScript locales, y después lo convertiremos en código Java.

Echo2 impone un esqueleto bastene ligero en el que se colocan los componentes. En esencia es una inclusión estática de script al código del motor del cliente ClientEngine.js y una declación de documento XHTML transicional. Por ejemplo la aplicación de demo de Chat de Echo2 al iniciarse se ve del siguiente modo:

<!DOCTYPE Html PUBLIC “-//W3C//DTD XHTML 1.0 Transitionsl//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<head>
<title> </title><meta content=”NextApp Echo v2.1.0.beta1″ name=”generator”/>
<script src=”/ChatClient/app=serviceId=Echo.ClientEngine” type=”text/javascript”>
</script>
</head>
<boty onload=”EchoClientEngine.init(‘/ChatClient/app’, true);” style=”position:absolute;font-family:verdana, arial, helvetica, sans-serif;font-size:10pt;height:100%;width:100%;padding:0px;margin:0px;overflow:hidden;”>
<form action=”#” id=”c_root” onsubmit=”return false;” style=”padding:0px;margin:0px;”/>
</body>
</html>

Eso es todo. El resto de las aplicaciones web Echo2 se ensambla dinámicamente mediante inserciones DOM dinámicas, obtenidas mediante llamadas AJAX.

Por tanto podemos crar un archivo XHTML estático similar al anterior y trabajar dentro del mismo.

La clave aquí está en utilizar una declaración XTHML transicional. Esto afecta al modo de trabajo del navegador. La otra clave está en la inclusión del ClientEngine.js mediante el sistema de archivos y no mediante URLs dinámicas, del siguiente modo:

<script type=”text/javascript” src=”file:///java/NextApp_Echo2/SourceCode/src/webrender/java/nextapp/echo2/webrender/resource/clientEngine.js”>

A partir de quí puede comenzar a prototipar tu componente.

Un Esqueleto de Archivo XHTML

A continuación tenemos un esqueleto de archivo XHTML que se puede utilizar para comenzar a prototipar tu nuevo componente. Obviamente debes arreglar los caminos absolutos utilizados para ajustarlos a tu sigutación.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<head>
<title> </title>
<meta content=”NextApp Echo v2.1.0.beta1″ name=”generator”/>
<script type=”text/javascript”
src=”file:///c:/java/NextApp_Echo2/SourceCode/src/webrender/java/nextapp/echo2/webrender/resource/ClientEngine.js”>
<script type=”text/javascript”
src=”file:///c:/java/echopointng/projects/jar/src/ui/java/echopointng/ui/resource/js/ep.js”>

<script type=”text/javascript”>

yourOnLoadInit = function() {
//
// aquí va tu código o puedes crear otro archivo .js que se incluya como el de arriba
};

</script>

</head>
<body onload=”yourOnLoadInit()” style=”position:absolute;font-family:verdana, arial, helvetica, sans-serif;font-size:10pt;height:100%;width:100%;padding:0px;margin:0px;overflow:hidden;”>

<form action=”#” id=”c_root” onsubmit=”return false;” style=”padding:0px;margin:0px;”>

<!– en Echo2 tu XHTML será hijo de este elemento y así debes hacerlo también –>

</form>
</body>
</html>

Diseño Previo de la Representación del Componente

Ahora hay que realizar un trabajo de diseño previo. Por ejemplo debes decidir el nombre de tu componente, que propiedades tendrá (en términos Java) y cómo se propagarán estas propiedades al cliente.

Supongamos que queremos un control con 5 propiedades del interfaz de usuario y con un comportamiento particular. No empieces a codificar hasta que conozcas esto.

También tendrás que decidir acerca de la estratégica de representación en tu XHTML. Debes decidir si vas a pre-representar el XHTML en el elemento de representación antes de que se invoque al código del cliente o si vas a “generar dinámicamente” los elementos DOM tú mismo en JavaScript basándote en los datos enviados al procesador de mensajes del lado cliente.

Estrategia de Pre Representación de XHTML

En esta estrategia, el XHTML es generado en el lado del servidor y enviado al cliente como un mensaje estándar de inserción DOM. En el momento en que se ejecuta el procesador del mensajes del lado cliente, todo el DOM XHTML debería estar en su lugar. Esto es genial si la mayoría del conocimiento necesario para construir la salida reside en el lado servidor. Por ejemplo un componente Table debe ejecutar sus TableCellRenders en el lado servidor para crear el aspecto de las filas. Y por tanto tiene sentido hacer esto en el servidor y crear el XHTML según se ejecutan.

El código JavaScript de cliente del componente realizará la asunción de que todo el XHTML que necesita ya está ahí.

Así que cuando prototipamos estáticamente dicho componente tenemos que asegurarnos que escribimos el XHTML que el componente esperaría que fuese procesado por el servidor.

Estrategia de Generación en el Cliente

En este diseño de estrategia, la generación de XHTML se realiza completamente en el lado cliente. El manejador de mensajes del lado cliente recibe todos los datos que necesita para poder crear elementos DOM dinámicamente para la representación del componente. Este tipo de componentes se ajusta bien al prototipado estático ya que está autocontenido en el propio código JavaScript.

Ejemplo – Estrategia de Generación Cliente – ColorChooser

El componente ColorChooser está desarrollado de tal modo que todo el DOM se crea en el código del lado cliente.

Todo lo que tenemos que hacer es proporcionar un contenedor padre en el que se colocará el selector de color. Esto reproduce lo que ocurre dentro del framework Echo2.

<div id=”c_177_parent”>

El otro truco consiste en simular el mensaje XML que llegaría al procesador de mensajes de ColorChooser desde su elemento de representación. De nuevo podemos hacerlos con un JavaScript hecho a mano. Simplemente creamos una estructura DOM XML equivalente a lo que llegaría desde el framework Echo2. Por ejemplo:

var itemXML = document.createElement(‘item’);
itemXML.setAttribute(‘eid’, ‘c_177’);
itemXML.setAttribute(‘container-eid’, ‘c_177_parent’);
itemXML.setAttribute(‘swatchesPerRow’, ’17’);
itemXML.setAttribute(‘enabled’, ‘true’);

itemXML.setAttribute(‘styleDefault’, ‘padding:1px;boder:1px solid #317082;’);
itemXML.setAttribute(‘styleSwatch’, ‘width:10px,height:10px;border:1px solid #000000;’);

//itemXML.setAttribute(‘colors’, ‘#1234#…|…|…’);
itemXML.setAttribue(‘colorTitles’, ”);

itemXML.setAttribute(‘interestedPartyId’, ‘c_189’);
itemXML.setAttribute(‘currentColorSelection’, ‘#ff33ff’);
itemXML.setAttribute(‘showCurrentColorSelectionSwatch’, ‘true’);
itemXML.setAttribute(‘currentColorSelectionText’, ‘Current Color : ‘);

var colorChooser = new EPColorChooser(‘c_177’);
colorChooser.init(itemXML);

Aquí estamos creando un elemento XML item y luego le fijamos atributos. Este es el modo exacto en que el elemento de representación de ColorChooser enviaría sus valores de propiedades. De echo esto ayuda a diseñar los nombres de las propiedades usados y el formato de los valores de las propiedades.

Ejemplo – Estrategia de Pre Representación de XHTML – TabEx

TabEx es un ejemplo en el que se utiliza la estrategia de pre-renpresentación xHTML. Se quería añadir la posibilidad de desplazar el cuerpo de la tabla sin mover la cabecera de la tabla a la vez que hacer que las columnas cambien de tamaño usando movimientos del ratón.

Se eligió esta estrategia por 2 motivos. El primero, que ya se tenía el XHTML codificado para representarlo en el servidor y además para que si el usuario no ponía el TableEx en modo “scrollable” no se quería que cambiase nada desde el punto de vista de la salida.

Así que se creó un archivo XHTML estático que incluía la librería básica Echo2 y las librerías EPNG.

Después se creó la estructura TabEx en XHTML estático como la generaría el elemento de representación de TabEx
<style>


.contentDivClass {
width:100%;
background-color:#00ff00;
height:200px;
overflow:scroll
}

td.cell1 {
border:1px blue solid;
overflow:hidden;
background-color:#DCDCDC;
overflow:hidden;
white-space:nowrap;
}

td.cell2 {
border:1px blue solid;
overflow:hidden;
background-color:#E9967A;
overflow:hidden;
white-space:nowrap;
}

td.cell3 {
border:1px blue solid;
overflow:hidden;
background-color:#FF8C00;
overflow:hidden;
white-space:nowrap;
}
</style>

<div id=”contentDiv” class=”contentDivClass”>


</tr>
<tr>
<td class=”cell1″>Column 1</td>
<td class=”cell2″>Column 2</td>
<td class=”cell3″>Column 3</td>
</tr>
<tr>
<td class=”cell1″>XXXXX X</td>
<td class=”cell2″>XXXXX X</td>
<td class=”cell3″>XXXXX X</td>
</tr>

Aunque en el XHTML estático usamos clases CSS, Echo2 no utiliza nombres de clase al generar los elementos (ya que muchos navegadores no soportan elementos de estilo dinámicos) sino que genera directamente el atributo style="xxxx;yyyy;".

Desde el punto de vista de codificación no nos preocupa ya que la salida XHTML se realiza en un bucle de programa y tiene el mismo esfuerzo tanto si tiene una celda como cientos. Pero en XHTML estático es un montón de Copiar y Pegar y parece mucho mas sencillo utilizar declaraciones de clases CSS.

Sin embargo un elemento a tener en cuenta de las clases CSS es que el JavaScript podría no hacer lo que queremos. Por ejemplo, dado el ejemplo de arriba, al llamar a este código:

var value = document.getElementById(‘cotentDiv’).style.width;
alert(value);

¿Nos devolverá 100%? ¿Quizás el ancho actual del elemento? No, devolverá la cadena vacía. Ya que el atributo de estilo del elemento no ha sido fijado a ningún valor.

Ahora escribiríamos todo el código como si estuviésemos en el framework Echo2 al final lo copiaríamos y pegaríamos de nuevo en el tableex.js real del proyecto EPNG y nos iríamos a la tarea de ajustar el TableExPeer para que genere el XHTML necesario para crear la tabla desplazable.

Vía

4 Responses to “Componentes personalizados en Echo2 – Parte III”


  1. […] El Blog de rubensa http://bitacora.rubensa.eu.org « msttcorefonts, fuentes de Window en Ubuntu Componentes personalizados en Echo2 – Parte III » […]


  2. […] Componentes personalizados en Echo2 – Parte III […]

  3. Manuel Says:

    Hola:Rubensa
    Mira tengo un problema con un war que cree en Echo2 en el id NetBeans. resulta que de ese archivo war solamente quiero ver una pantalla en especifico cual seria la url que me lleve a la pantalla especificada o enque archivo puedo modificar para acceder solo a una pantalla?

  4. P M Says:

    mira necesataria que me pudieses dar una mano con el echo 2 integrado a hibernate si tienes un ejemplo trabajando con una base de datos te agradecerias me dieras una mano.


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: