Echo2 is the current stable version of the framework. The 2.1RC releases are recommended for production use. A 2.1.0 version will be released in the very near future.

Download Echo2

Nous avons choisi de faire une sortie de 4 heures en catamaran avec Echo2. Au programme : ballade au large de Key West, au milieu d'îles désertes avec rencontre de dauphins (qui malheureusement n'ont pas été au rendez-vous, ce sont des choses qui arrivent, il faut le savoir) et plongée masque et tuba (snorkeling), un moment inoubliable! Nous avons même vu un requin des sables et une raie. A bord, nous n'étions que 2 couples de touristes et le personnel de bord, à savoir la skipper et le barman, et oui, un barman pour nous servir (sodas, vin, bières, et fruits exotiques histoire d'essayer de garder la ligne ce qui n'est pas gagné!). Bref, un équipage jeune et super sympa.

L'après-midi, ballade dans l'île. Tout se fait à pied mais vous pouvez aussi louer scooters, bicyclettes ou encore voiturettes.

Autre chose à ne pas rater à Key West : le coucher du soleil sur Mallory Square, très romantique!

Puis dîner chez Willie T's sur Duval Street. Dégustation d'un plat local : un poisson frais et son chutney d'ananas, fricassée de patates douces et légumes sautés au wok...un régale!

 Chez Willie T's, il est possible de laisser un témoignage de son passage en écrivant un petit mot sur un billet d'1 dollar que la serveuse vous proposera d'agrapher au mur! Dépéchez-vous, il ne reste plus beaucoup de place, même le plafond est tapissé de billets! Peut-être y verrez-vous le nôtre :-)

http://jl2tho.blogspot.com/2007/10/resume-decideurs-echo2-ajax-java.html

Il existe deux frameworks plus ou moins équivalents que sont GWT (Google Web Toolkit) et Echo2. L'un comme l'autre permet de concevoir une application Ajax sans écrire une seule ligne de code en JavaScript. Leur principe est de proposer une librairie Java et un compilateur qui converti le code de cette librairie en JavaScript. Mais bien que reposant sur le même principe général, ces deux frameworks sont en fait très différents.

GWT distingue de façon très nette les parties cliente et serveur. La première est intégralement compilée en JavaScript et peut être exportée vers n'importe quel serveur Web tel que Apache, tandis que la partie serveur est destinée à tourner sur un conteneur de Servlet tel Tomcat. Bien sûr, il est possible de faire tourner le tout sur Tomcat, mais seules les librairies pouvant être compilées en JavaScript peuvent être inclues dans le code de la partie cliente.

En revanche, Echo2 n'offre pas de cadre pour distinguer le côté serveur et le côté client, il appartient au développeur de s'en tenir au design pattern adéquate. Et à la différence de GWT, Echo2 génère une véritable application Java dont le code est intégralement délivré par des Servlets. Il n'est donc pas possible d'exporter une application Echo2 vers un simple serveur Web.

Quel que soit le choix de la technologie, les frameworks Ajax ont l'avantage, pour un développeur Java, de pouvoir se lancer dans l'écriture de Services Web complexes. On signalera enfin l'existence d'une librairie Ajax conçue spécifiquement pour le framework JSF et qui s'appelle Ajax4Jsf, nous aurons l'occasion d'y revenir.

Recientemente he traducido el tutorial oficial de Echo2 al español y está disponible en mi página web para todo aquel que esté interesado en introducirse en este framework de desarrollo basado en AJAX.

• Componentes personalizados en Echo2 - Parte I
• Componentes personalizados en Echo2 - Parte II
• Componentes personalizados en Echo2 - Parte III

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">
<html xmlns="http://www.w3.org/1999/xhtml">
<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">
<html xmlns="http://www.w3.org/1999/xhtml">
<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

• Componentes personalizados en Echo2 - Parte I
• Componentes personalizados en Echo2 - Parte II
• Componentes personalizados en Echo2 - Parte III

En este artículo continuaremos examinando mas características que podemos añadir a los componentes para convertirlos en mas ricos de cara al usuario. Usaremos como componente de ejemplo el echopoint.ExpandableSection de EchoPointNG. Tal vez quieras bajarte su código fuente para estudiarlo según avanzamos.

Procesador de Mensajes

Echo2 tienen un motor JavaScript en el cliente que se encarga de mantener el lado del servidor y del cliente sincronizados. Con nuestro anterior componente de ejemplo RulerLine, el estado del componente no podía cambiar y por tanto no se necesitaba ningún código JavaScript.

Sin embargo ¿qué ocurre con un componaente más complejo que se pueda pulsar o editar o expandir? ¿Cómo son estas configuraciones del componente y cómo se reflejan los cambios de estado de vuelta en el servidor?

Aquí es donde aparece el motor cliente de Echo2 y es donde aparece su uso del Procesador de Mensajes de JavaScript.

Cuando se representa un componente en el servidor usando su método renderAdd(), se obtiene el XHTML y se envía como un mensaje XML al motor del lado cliente. Este tiene un código conocido como el EchoDomUpdate.MessageProcesor que es el responsable de interpretar el mensaje XML y de colocar el XHTML en el DOM del navegador.

No necesitas escribir nada de JavaScript para que esto ocurra. Es código estándar del framework.

Sin embargo puedes escribir tus propios procesadores de mensajes del lado cliente. Esto te permitirá realizar funciones extra como la adición y eliminación de manejadores de eventos XHTML o la inicialización del estado del componente en el cliente de algún modo.

Un procesador de mensajes es simplemente una función JavaScript con el nombre estandar de process.

Por ejemplo, el componente EPNG ExpandableSection tienen un procesador de mensajes llamado EPExpandableSection.MessageProcesor.process.

Cuando el motor cliente de Echo2 recibe un mensaje XML, este viene marcado con el nombre del procesador de mensajes a invocar. Es responsabilidad del procesador de mensajes el hacer algo con dicho mensaje. El elemento de representación del lado del servidor creará el mensaje XML para que sea enviado al procesador de mensajes del lado cliente. Por ejemplo, aquí tenemos un trozo de código de ExpandableSection que se llama cuando se añade el componente por primera vez a la jerarquía.

protected void createInitDirective(RenderingContext rc, ExpandableSection es, Style fallbackStyle) {
Element itemizedUpdateElement = rc.getServerMessage().getItemizedDirective(ServerMessage.GROUP_ID_POSTUPDATE, "EPExpandableSection.MessageProcessor", "init", new String[0], new String[0]);
Element itemElement = rc.getServerMessage().getDocument().createElement("item");
itemElement.setAttribute("eid", rc.getElementId());
itemElement.setAttribute("expanded", String.valueOf(es.isExpanded()));
ExpansionGroup group = (ExpansionGroup)rc.getRP(ExpandableSection.PROPERTY_EXPANSION_GROUP, fallbackStyle);
if (group != null) {
itemElement.setAttribute("groupId", group.getRenderId());
itemElement.setAttribute("acoordionMode", String.valueOf(group.isAcocordionMode()));
}
TitleBar tb = (TitleBar)rc.getRP(ExpandableSection.PROPERTY_TITLEBAR, fallbackStyle);
if (tb != null) {
itemElement.setAttribute("titleBarId", ContainerInstance.getElementId(tb));
}
itemizedUpdateElement.appendChild(itemElement);
}

Fíjate en la parte de getServerMessage().getItemizedDirective(...). Esto crea un mensaje de directiva XML y marca su procesador de mensajes como "EPExpandableSection.MessageProcesor". Esto es lo que permite al motor del lado cliente conocer a qué procesador de mensajes invocar.

El código de arriba fija algunos atributos XML en el elemento XML basados en las propiedades de ExpandableSection. Más acerca de esto después.

Lo más normal es hacer un init o dispose de algún modo en el componente. Por ejemplo, aquí está el código JavaScript del cliente para el procesador de mensajes de ExpandableSection.

EPExpandableSection.MessageProcessor.process = function(messagePartElement) {
for (var i=0; i<messagePartElement.childNodes.length; ++i) {
if (messagePartElement.childNodels[i].nodeType == 1) {
switch (messagePartElement.childNodes[i].tagName) {
case "init":
EPExpandableSection.MessageProcessor.processInit(messagePartElement.childNodes[i]);
break;
case "dispose":
EPExpandableSection.MessageProcessor.processDispose(messagePartElement.childNodes[i]);
break;
case "expansion":
EPExpandableSection.MessageProcessor.processExpansion(messageParteElement.childNodes[i]);
break;
}
}
}
};

Puede manejar 3 tipos diferentes de mensajes. Un mensajes XML init, un mensaje XML dispose y un mensaje XML expansion. Veamos el procesamiento del mensaje init.

EPExpandableSection.MessageProcessor.processInit = function(initMessageElement) {
//debugger;
for (var item=initMessageElement.firstChild; item; item=item.nextSibling) {
var elementId = item.getAttribute("eid");
EP.ObjectMap.destroy(elementoId);
var es = new EPExpandableSection(elementId);
if (item.getAttribute("enabled") == "false") {
EchoDomPropertyStore.setPropertyValue(elementId, "EchoClientEngine.inputDisabled", true);
}
var groupId = item.getAttribute("groupId");
if (groupId) {
es.setButtonGroup(elementId, groupId);
}
es.accordionMode = (item.getAttribute("accordionMode") == 'true');
es.titleBarId = item.getAttribute("titleBarId");
es.contentE = document.getElementById(elementId+'|Content');
}
}

Este código recorre los hijos de nivel superior del mensajes XML. Para cada hijo de nivel superior comprueba el valor del atributo eid. Este es el id del componente. Entonces el código crea un objetos "del lado cliente" para el ExpandableSection y le fija varias propiedades según los valores del mensaje XML.

Como puedes ver el estado del servidor se transfiere al cliente mediante mensajes de directiva XML y el procesador de mensajes.

Siguiendo con el ejemplo completo, mira al atributo enabled en la directiva XML. Si este es false significa que el componente debería estar deshabilitado en el cliente. El código especial que aparece se asegura que el componente esté marcado como no disponible.

El otro mensaje del ciclo de vida es dispose. Este se crea en el método renderDispose() en el lado del servidor. Este es el modo que tiene el framework de indicar al elemento de representación que el componente no va a ser necesario más tanto en el lado del servidor como en el lado del navegador cliente.

El ExpandableSectionPeer hace lo siguiente en el servidor

public void renderDispose(RenderContext rc, ServerComponentUpdate update, Component component) {
super.renderDispose(rc, update, component);
createDisposeDirective(rc.getServerMessage(), component);
}

protected void createDisposeDirective(ServerMessage serverMessage, Component component) {
Element itemizedUpdateElement = serverMessage.getItemizedDirective(ServerMessage.GROUP_ID_PREREMOVE, "EPExpandableSection.MessageProcessor", "dispose", new String[0], new String[0]);
Element itemElement = serverMessage.getDocument().createElement("item");
itemElement.setAttribute("eid", ContainerInstance.getElementId(component));
itemizedUpdateElement.appendChild(itemElement);
}

Este código crea un mensaje de directiva XML de "dispose" para enviarlo al cliente y para ser manejado por el procesador de mensajes EPExpandableSection.MessageProcessor.

Esto permite al código del lado cliente limpiar cualquier recurso del componente del lado cliente como manejadores de evento, etc... Aquí tenemos el código del procesador de mensajes ExpandableSection:

EPExpandableSection.MessageProcessor.processDispose = function(disposeMessageElement) {
for (var item=disposeMessageElement.firstChild; item; item=item.nextSibling) {
var elementId = item.getAttribute("eid");
EP.ObjectMap.destroy(elementId);
}
};

Este código usa una librería JavaScript de EchoPointNG para limpiar el objeto del lado cliente.

Actualizaziones Parciales y Procesadores de Mensaje

Ahora todo componente que tiene un procesador de mensajes tendrá, por convenio, un init y un dispose, ya que esto refleja el ciclo de vida de prácticamente todos los componentes.

Pero ¿qué pasa con el resto de eventos o cambios de estado que ocurren en el servidor?

ExpandableSection tienen una propiedad 'expansion' que se envía al lado cliente de representación del componente. Cuando es true, el código cliente debe expandir el área de contenido del componente. Cuando es false, debe contraer el área de contenido.

Ahora el componente ExpandableSection escucha a su modelo de expansion para controlar su estado de expansión. Aquí tenemos el código:

private class InternalExpansionModelListener implements ChangeListener {
/*
* @see nextapp.echo2.app.event.ChangeListener#stateChanged(nextapp.echo2.app.event.ChangeEvent)
*/
public void stateChange(ChangeEvent e) {
ExpansionModel expansionModel = (ExpansionModel) e.getSource();
//
// if an expansion model other than ours, ie the titlebar, tells
// us of an expansion event, then update out model.
if (expansionModel != null) {
if (expansionModel != getExpansionModel()) {
setExpanded(expansionModel.isExpanded());
} else {
// set the titlebar to reflect our expansion
if (getTitleBar() != null && getTitleBar().getExpansionModel() != null) {
getTitleBar().getExpansionModel().setExpanded(expansionModel.isExpanded());
}
}
firePropertyChange(EXPANDED_CHANGED_PROPERTY, null, null);
}
}
}
private ChangeListener internalExpansionListener = new InternalExpansionModelListener();

Lanza la propiedad EXPANDED_CHANGED_PROPERTY cuando el modelo cambia. Esto hace que el componente sea marcado como necesita actualización por el framework Echo2. El elemento de representación será invocado para representar el objeto sucio.

Supongamos que el estado de expansión es la única propiedad que ha cambiado y que la ExpandableSection ya existe en la gerarquía de componentes. En este caso se llamará al método renderUpdate(). Echémosle un ojo. Realmente se toma de su clase padre AbstractEchoPointContainerPeer.

public boolean renderUpdate(RenderContext rc, ServerComponentUpdate update, String targetId) {
boolean fullReplace = false;
if (update.hasUpdatedLayoutDataChildren()) {
fullReplace = true;
}
if (update.hasUPdatedProperties()) {
if (partialUpdateManager.canProcess(rc, update)) {
partialUpdateManager.process(rc, update);
} else {
fullReplace = true;
}
}
return renderUpdateBaseImpl(rc, update, targetId, fullReplace);
}

La explicación de este método es un poco complicada.

El objeto ServerComponentUpdate contiene información acerca de los cambios. En este caso la propiedad expanded ha cambiado. El elemento de representación utiliza un objeto PartialUpdateManager para determinar si puede manejar los cambios de propiedades.

El PartialUpdateManager contiene una serie de objetos PartialUPdateParticipan cuya clave son los nombres de propiedades. El que maneja la propiedad "expanded" es el siguiente:

partialUpdateManager.add(ExpandableSection.EXPANDED_CHANGE_PROPERTY, new PartialUpdateParticipant() {
/**
* @see nextapp.echo2.webcontainer.PartialUpdateParticipan@canRenderProperty(nextapp.echo2.webcontainer.RenderContext, nextapp.echo2.app.update.ServerComponentUpdate)
*/
public boolean canRenderProperty(RenderConext rc, ServerComponentUpdate update) {
return true;
}

/**
* @see nextapp.echo2.webcontainer.PartialUPdateParticipant#renderProperty(nextapp.echo2.webcontainer.RenderConext, nextapp.echo2.app.update.ServerComponentUpdate)
*/
public void renderProperty(RenderContext rc, ServerComponentUpdate update) {
ExpandableSection tb (ExpandableSection) update.getParent();
boolean isExpanded = tb.isExpanded();
// an XML message directive please to tell the popup to expand!
Element itemizedUpdateElement = rc.getServerMessage().getItemizedDirective(ServerMessage.GROUP_ID_POSTUPDATE, "EPExpandableSection.MessageProcessor", "expansion", new String[0], new String[0]);
Element itemElement = rc.getServerMessage().getDocument().createElement("item");
itemElement.setAttribute("eid", ContainerInstance.getElementId(tb));
itemElement.setAttribute("expanded", String.valueOf(isExpanded));
itemElement.appendChild(itemElement);
}
});

Lo que hace esto es comprobar las actualizaciones de la propiedad expanded. Coge el valor del componente y crea un mensaje de directiva XML para el ExpandableSection.MessageProcessor y le asigna la clave con el nombre expansion y se fija el valor del estado de expansión.

Este mensaje viaja al cliente y el código JavaScript del cliente es el responsable de actualizar el estado de ExpandableSection para abrirlo o cerrarlo, dependiendo del valor. Esto se realiza usando este código:

EPExpandableSection.MessageProcessor.processExpansion = function(disposeMessageElement) {
// debugger;
for (var item = disposeMessageElement.firstChild; item; item = item.nextSibling) {
var elementId = item.getAttribute("eid");
var expanded = (item.getAttribute("expanded") == 'true');
var es = EP.ObjectMap.get(elementId);
if (es != null) {
es.onTibleBarExpansion(expanded);
}
}
};

No se ha añadido XHTML al cliente. No se ha realizado ni un solo añadido o eliminación al DOM. Solamente se ha enviado al cliente el cambio de la propiedad expansion y éste se ha reflejado.

Este mecanismo de actualización parcial significa que las aplicaciones Echo2 pueden realizar grandes trucos visuales sin la sobrecarga de grandes mensajes XML o eliminación y adición extra de XHTML.

El framework de actualización de Echo2 y PartialUpdateManager en particular, es suficientemente potente para que sepa si una serie de cambios de propiedades se pueden manejar o no. En este caso si las actualziaciones no se pueden manejar por el PartialUpdateManager, entonces devolverá false y se lleavará a cabo una sustitución completa (eliminación DOM/adición DOM).

La frecuencia con la que se llevará a cabo una sustitución total depende de tí como diseñador del elemento de representación. Un control más fino de las propiedades puede significar más código y estado en el cliente y el servidor pero menos tráfico de mensajes XML/XHTML y menos actualizaciones del DOM.

Un control menos fino de actualizaciones de propiedades hacen que el código de representación sea más sencillo y puede ser más sensible a muchos cambios de propiedades.

Algo que habrán notado los lectores más astutos es que la creación de la directiva de mensaje XML realmente contiene un mensaje XML de múltiples partes.

El procesador de mensajes por tanto debe recorrer en un bucle cada parte del mensaje y ejecutar el código apropiado para cada elementId. Esto signifiaca mucha mas "eficiencia de mensajería" que mensajes individuales para cada componente.

Actualizaciones Parciales y actualizaciones DOM estándar

Algunas propiedades de los componentes se pueden manejar de un modo sencillo de manera estándar. Por ejemplo si cambiamos el color de fondo de un componente, generalmente solamente es necesario modificar el estilo de color de fondo del elemento XHTML.

Echo2 tiene varios PartialUpdateParticipant predefinidos como el ColorUpdate, el BorderUpdate y el InsetsUpdate. En esencia crean un mensaje DOM especial que simplemente cambia propiedades específicas de estilo. Por ejemplo el código de ColorUpdate es algo así:

public void renderProperty(RenderContext rc, ServerComponentUpdate update) {
Color color = (Color)update.getParent().getRenderProperty(Component.PropertyName);
String elementId = idSuffix == null ? ContainerInstance.getElementId(update.getParent()) : ContainerInstance.getElementId(update.getParent()) + idSuffix;
if (color == null) {
DomUpdate.renderStyleUpdate(rc.getServerMessage(), elementId, cssAttributeName, "");
} else {
DomUpdate.renderStyleUpdate(rc.getServerMessage(), elementId, cssAttributeName, ColorRender.renderCssAttributeValue(color));
}
}

El código DomUpdate.renderStyleUpdate() crea para tí el XML de actualización de estilo DOM de un modo estándar que el EchoDomUpdate.MessageProcessor pueda entender.

Manejadores de Eventos del Lado Cliente

Supongamos que queremos representar un componente similar a un Button en el que se pueda pulsar, en cuyo caso enviará un evento al servidor, informándole acerca de la pulsación. Desde luego podríamos hacer esto:

<button onclick="myfunction(event)">Click me⪫button>

Realmente no todos los navegadores soportan la adición "automática" de manejadores de evento como la de arriba. Así que debemos añadir dinámicamente los manejadores de evento en la fase de inicialización (init) del procesador de mensajes del componente. El siguiente código está tomado del procesador de mensages del Button de Echo2.

EchoEventProcessor.addHandler(elementId, "click", "EchoButton.processClick");
EchoEventProcessor.addHandler(elementId, "keypress", "EchoButton.processKeyPressed");
EchoEventProcessor.addHandler(elementId, "mousedown", "EchoButton.processPressed");
EchoEventProcessor.addHandler(elementId, "mouseout", "EchoButton.processRolloverExit");
EchoEventProcessor.addHandler(elementId, "mouseover", "EchoButton.processRolloverEnter");
EchoEventProcessor.addHandler(elementId, "mouseup", "EchoButton.processReleased");

El motor cliente de Echo2 proporciona el EchoEventProcessor.addHandler para añadir eventos a elementos XHTML con nombre. El framework JavaScript maneja por tí los diferentes modos de añadir manejadores de eventos.

Así, cuando el ratón pasa sobre el botón (un evento mouseover) se llamará a la función JavaScript EchoButton.processRolloverEnter.

Ahora, cuando no se necesitará más el componente, los manejadores de eventos deben ser eliminados, de otro modo pueden ocrrurir errores de memoria. Aquí está el código para el manejador de la fase dispose del Button de Echo2.

EchoButton.MessageProcessor.processDispose = function (disposeMessageElement) {
for (var item = disposeMessageElement.firstChild; item; item = item.nextSibling) {
var elementId = item.getAttribute("eid");
EchoEventProcessor.removeHandler(elementId, "click");
EchoEventProcessor.removeHandler(elementId, "keypress");
EchoEventProcessor.removeHandler(elementId, "mousedown");
EchoEventProcessor.removeHandler(elementId, "mouseout");
EchoEventProcessor.removeHandler(elementId, "mouseover");
EchoEventProcessor.removeHandler(elementId, "mouseup");
}
}

Propiedades de Componente contra Propiedades de Representación de Componente

Los componentes Echo2 tienen propiedades normales Java tales como getBackground() y getFont(). Y se puede utilizar para fijar propiedades visuales para controlar cómo se comporta y aparece un componente. Y llamaremos a los getters y setters normales de Java para fijar estas propiedades, ej: component.setColor(Color.RED);

Echo2 tiene otro mecanismo llamado Styles (Estilos) que permite que se fijen y se apliquen propiedades visuales a una serie de componentes. Esto permite que un conjunto de propiedades visuales se apliquen a varios componentes.

Otra variación es esto son las StyleSheets (Hojas de Estilo) que son una colección de Styles clasificados por clase de componente y nombre de estilo. Se puede obtener más información relativa a este asunto en http://nextapp.com/platform/echo2/doc/tutorial/styles.html

Cuando el elemento de representación accede a las propiedades del componente para "representarlo" DEBE utilizar el método getRenderedProperty para acceder al valor de la propiedad, no a los métodos getter normales. Esto asegura que se siga el orden apropiado para buscar los valores de las proiedades. Este es el código de Component.getRenderedProperty() donde podemos ver el orden en acción.

public final Object getRenderProperty(String propertyName, Object defaultValue) {
Object propertyValue = localStyle.getProperty(propertyName);
if (propertyValue != null) {
return propertyValue;
}
if (sharedStyle != null) {
propertyValue = sharedStyle.getProperty(propertyName);
if (propertyValue != null) {
return propertyValue;
}
}
if (application != null) {
Style applicationStyle = applicationInstance.getStyle(getClass(), styleName);
if (applicationStyle != null) {
// Return style value specified in application.
propertyValue = applicationStyle.getProperty(propertyName);
if (propertyValue != null) {
return propertyValue;
}
}
}
return defaultValue;
}

Así, por ejemplo, para obtener el color de fondo de un componente debemos escribir:

Color background = (Color)mycomponent.getRenderedProperty(Component.PROPERTY_BACKGROUND);

y no esto:

Color background = mycomponent.getBackground();

Echo2 tiene una serie de clases de ayuda que puede manejar propiedades visuales estandar como Colores, Fuentes y Bordes en representaciones CSS. Por ejemplo aquí tenemos parte del código de representación del Button que trabaja con propiedades visuales:

...
border = (Border) button.getRenderProperty(AbstractButton.PROPERTY_BORDER);
foreground = (Color) button.getRenderProperty(AbstractButton.PROPERTY_FOREGROUND);
background = (Color) button.getRenderProperty(AbstractButton.PROPERTY_BACKGROUND);
font = (Font) button.getRenderProperty(AbstractButton.PROPERTY_FONT);
backgroundImage = (FillImage) button.getRenderProperty(AbstractButton.PROPERTY_BACKGROUND_IMAGE);
}

BorderRender.renderToStyle(cssStyle, border);
ColorRender.renderToStyle(cssStyle, foreground, background);
FontRender.renderTyStyle(cssTyle, font);
FillImageRender.renderToStyle(cssStyle, rc, this, button, IMAGE_ID_BRACKGROUND, backgroundImage, FillImageRender.FLAG_DISBLE_FIXED_MODE);
InsetsRender.renderToStyle(cssStyle, "padding", (Insets)button.getRenderProperty(AbstractButton.PROPERTY_INSETS));

Vía

• Componentes personalizados en Echo2 - Parte I
• Componentes personalizados en Echo2 - Parte II
• Componentes personalizados en Echo2 - Parte III

El framework Echo2 viene con una serie de componentes predefinidos que te permiten construir una aplicación Web. Sin embargo quizás quieras construir los tuyos propios que vayan mas allá de los básicos que trae el framework.

Una forma de crearte tus propios componentes consistiría en la composición de varios de los ya existentes. Por ejemplo podríamos crearnos nuestro propio componente LoginPanel como una simple composición de un Grid, un TextField y un Button. Y podríamos añadirles document listeners y action listeners para que actuen como un único componente.

Pero ¿qué ocurre si queremos crear un componente que simplemente no existe o si lo que queremos es modificar significativamente el modo en que trabaja un componente? Para conseguir esto tenemos que escribir nuestro propio componente con su correspondiente elemento de representación (rendering peer).

Un ejemplo sencillo

Comencemos creando un sencillo componente llamado RulerLine. Este componente nos pemitirá dibujar una línea horizontal en la parte cliente. Aunque es un componente tremendamente sencillo ya que no tiene entrada por parte del usuario y no necesita un control de estado especial nos servirá como comienzo.

/**
* <code>RulerLine</code> es un componente muy sencillo
*/
public class RulerLine extends Component {
}

Aunque podría parecer que aún no tenemos nada, lo cierto es que con esto ya tenemos un componente que soporta colores de fondo y de primer plano, sus propias fuentes y que además puede formar parte de la gerarquía de componententes de Echo2.

Mapeo de componente con su par de representación

Echo2 utiliza un truco de recursos Java para mapear un componente a su representación. Cuando tienen un componente que representar, busca todas las instacias de un archivo de propiedades especial y busca en estas instancias el mapeo entre la clase del componente y su clase correspondiente de representación.

El nombre del archivo de propiedades es:

/META-INF/nextapp/echo2/SynchronizePeerBindings.properties

Solamente necesitas situar este archivo en el raiz de tu archivo JAR y Echo2 lo encontrará haciendo uso de su nombre y lo revisará para encontrar el mapeo necesario.

Siguiendo con nuestro ejemplo, crearemos el archivo /META-INF/nextapp/echo2/SynchronizePeerBingins.properties en nuestro archvio JAR y escribiremos lo siguiente:

example.RulerLine example.ui.RulerLinePeer

Lo que indicará al framework Echo2 que el componente RulerLine es representado por su par de representación RulerLinePeer.

Elementos de representación

Los elementos de representación en Echo2 no tienen estado. Se utiliza una misma instancia de un elemento de representación para TODOS los componentes que están mapeados con ella. Esto ayuda a reducir la cantidad de memoria de una aplicación web Echo2. Esto también quiere decir que debemos ser cuidadosos al escribir el código de los elementos de representación y asegurarnos de no fijar variables de instancia, etc...

El elemento de representación se encarga de "representar" XML y normalmente contenido XHTML en unos mensajes XML especiales que se envían al motor AJAX de Echo2 que se encuentra en el navegador cliente.

El motor AJAX cliente sabe como interpertar muchos de estos mensajes y realiza acciones como la adición/eliminación DOM y cosas por el estilo.

No explicaremos la estructura de los mensajes XML ya que raramente es necesario conocerla. Echo2 realiza un buen trabajo en cuanto a la "encapsulación" de los mismos en llamadas a un API Java de tal modo que nunca veas el XML que viaja. En su lugar, todo se transforma de y en objetos Java.

Puedes ver los mensajes XML enviados y devueltos añadiendo el parámetro "debug" a la URL de tu aplicación Echo2. Esto abre un panel de depuración que muestra todas las comunicaciones con el servidor en tiempo real.

Por ejemplo http://demo.nextapp.com/Email/app?debug mostrará la aplicación de ejemplo Email de Echo2 con el panel de depuración en acción.

Añadiendo XHTML al DOM del cliente

Un elemento de representación debe implementar una interfaz especial llamada

nextapp.echo2.webcontainer.ComponentSynchronizePeer

Durante el ciclo de vida del proceso de representación se llamará a los métodos de esta interfaz.

Se llama a ComponentSynchronizePeer.renderAdd para añadir la representación XHTML del componente en el navegador cliente. Hay dos modos de realizar esto, pero nos centraremos en el más habitual que consiste en la adición DOM.

Existe un concepto de componente de representación puro de cliente. Sin embargo se trata de un concepto avanzado que no contemplaremos en esta parte del tutorial.

Echo2 tiene una serie de características que permite añadir contenido XHTML al Document Object Model (DOM - Modelo de objetos de documento) en el navegador cliente.

Si tu elemento de representación utiliza este mecanismo para añadir XHTML al servidor (y la mayoría lo hacen) también debes soportar otro interfaz especial llamado

nextapp.echo2.webcontainer.DomUpdateSupport

Tiene un único método llamado renderHtml que puede llamarse para representar el XHTML que se enviará al navegador cliente y que será insertado en el DOM.

Aquí tenemos el código

public void renderHtml(RenderContext rc, ServerComponentUpdate update, Node parentNode, Component component) {
Document doc = rc.getServerMessage().getDocument();
Element hrE = doc.createElement("hr");
hrE.setAttribute("id", ContainerInstance.getElementId(component));
parentNode.appendChild(hrE);
}

Este sencillo elemento de representación simplemente crea una instancia de org.w3c.dom.Element con la etiqueta de nombre hr. Luego fija el id de la etiqueta XHTML con un valor único que identifica al componente. El resultado en la red de todo esto es que se genera el siguiente XHTML

<hr id="c_1234" />

Sin embargo realmente ocurren muchas cosas por detrás. Los objetos RenderContext y ServerComponentUpdate mantienen una gran cantidad de información que puede ser importante para tu elemento de representación. Estos permiten realizar "trucos" como la actualización parcial y cosas por el estilo. Para dejar las cosas sencillas de momento no los usaremos.

Ahora veamos el método renderAdd. Aquí es donde ocurre la "magia" realmente

public void renderAdd(RenderContext rc, ServerComponentUpdate update, String targetId, Component component) {
Elemnt domAddElement = DomUpdate.renderElementAdd(rc.getServerMessage());
DocumentFragment htmlFragment = rc.getServerMessage().getDocument().createDocumentFragment();
renderHtml(rc, update, htmlFragment, component);
DomUpdate.renderElementAddContent(rc.getServerMessage(), domAddElement, targetId, htmlFragment);
}

Lo que hace esto es crear una directiva de mensaje XML especial que informa al motor del lado cliente de Echo2 que queremos añadir XHTML al DOM.

Esto se realiza mediante el siguiente código Java

Element domAddElement = DomUpdate.renderElementAdd(rc.getServerMessage());

Si miramos más a fondo en la clase DomUpdate veremos cómo crear una sección especial en el documento XML que será interpretada en el navegador cliente por el motor AJAX de Echo2.

Luego se llama a este código

DocumentFragment htmlFragment = rc.getServerMessage().getDocument().createDocumentFragment();
renderHtml(rc, update, htmlFragment, component);

La primera línea crear un objeto contenedor especial llamado DocumentFragment en el DOM w3c. Se trata de un objeto marcador especial que no genera XML pero que permite las relaciones de padre/hijo en una estrucutra DOM.

La segunda línea llama a nuestro método renderHtml utilizando el fragmento de documento como nodo padre. Se generará el XHTML <hr id="c_1234" />.

DomUpdate.renderElementAddContent(rc.getServerMessage(), domAddElement, targetId, htmlFragment);

La última línea añade el XHTML generado al mensaje XML que se enviará al motor AJAX de Echo2 del navegador cliente.

Echo2 "agrupará" varias actualizaciónes de componententes y los pondrá en un mensaje XML para enviarlos al navegador cliente. Esto es así por motivos de rendimiento. Por ejemplo, la pulsación de un botón podría resultar en la modificación de 10 componentes. Las 10 actualizaciones se enviarán de vuelta en una unica interacción XML servidor/cliente.

Cuando el motor AJAX de Echo2 del cliente recibe este mensaje XML añadirá nuestro XHTML en el lugar correcto del DOM cliente.

Actualizando XHTML en el DOM cliente

Imaginemos que cambia una propiedad en nuestro componente RulerLine. Echo2 sabe que el componente ya está representado en el navegador cliente así que no lo volverá a añadir. En su lugar, detectará este cambio de propiedad y llamará al método renderUpdate.

Así, tenemos la oportunidad de actualizar la representación del componente en el cliente. Sin embargo como es un componente sencillo no aprovecharemos las maravillas de la "actualización parcial" sino que lo que haremos será eliminar el componente y volverlo a añadir. Este es nuestro sencillo mecanismo de "actualización". Posteriormente añadiremos soporte para actualizaciones parciales.

Veamos el método

public boolean renderUpdate(RenderContext rc, ServerComponentUpdate update, String targetId) {
DomUpdate.renderElementRemove(rc.getServerMessage(), ContainerInstance.getElementId(update.getParent()));
renderAdd(rc, update, targetId, update.getParent());
return false;
}

La primera línea crear un mesaje de directiva XML que se utilizará para indicar al motor AJAX del cliente que elimine un cierto elemento DOM por id.

Ahora, si te fijas, verá que el id que aparece aquí no es el id de nuestro componente RulerLine sino un componente devuelto usando update.getParent().

Bien, realmente eso no está bien. El método getParent() no tiene demasiado sentido. El padre en este caso es el componente en cuestion (RulerLine) y se llama padre (parent) porque puede haber tenido componentes hijos modificados. Seguramente hubiese sido mejor llamar a este método algo así como getTargetComponent() para evitar confusiones.

Así que al final, lo que vemos es que el elemento con nuestra id será eliminado del DOM.

La segunda línea llama al método renderAdd() de nuevo para añadir el nuevo XHTML para el RulerLine ya que ya habrá sido eliminado. Este es el modo más sencillo de actualizar la represencitación de un componente en el lado cliente, la llamada estrategia de eliminar/re-añadir.

El framework Echo2 es muy cuidadoso en cuanto al orden en el que procesa estos mensajes de directiva XML. Las eliminaciones simpre se realizan antes que la adiciones.

Eliminando XHTML del DOM cliente

Para nuestro sencillo component no tenemos que hacer nada. Echo2 conoce el id del componente en el DOM y por tanto puede "eliminarlo" enviando un mensaje de directiva XML por nosotros.

Sin embargo, si necesitamos limpiar alguna cosa se invoca al método renderDispose(). En nuestro caso nosotros no hacemos nada sin embargo lo podríamos utilizar para enviar directivas XML especiales para limpiar los recursos del lado del cliente tales como manejadores de eventos y demás.

public void renderDispose(RenderContext rc, ServerComponentUpdate update, Component component) {
// no tenemos que hacer nada
}

Vía

As a reminder, I created a meta-model that represented a web-based user interface. The model is basically a set of containers:
Scenarios contain Pages. Pages contain Sections. Sections can contain other sections
or Widgets. Widgets can be output text, input fields, menus, calendars, links to other pages, etc.

So, my first workflow creates a Java Server Faces (JSF) application. The macros generate all JSP files and all pagecode Java files. The web.xml and faces-config.xml files are also generated, including the navigation rules between the pages.

My second workflow creates HTML documentation and a input file to graphviz (which is a great free tool from AT&T for quick-and-easy graphing and I highly recommend you play with it). <blogPost topic="graphviz" todo="true"/>

After much work on the JSF workflow (due to the requirement to produce a real working application), I have now moved on to an evaluation phase. I am looking at more Ajaxy/Web 2.0-type applications. (aknowledging that you can do Ajax with JSF).

My third workflow creates an Echo2 application. Echo2 is an excellent framework from NextApp. Tod Liebeck, the lead developer of Echo2, has an interesting article comparing GWT and Echo2 on theserverside.com. In order to generate the Echo2 code, I made the assumption that a "Page" model class mapped to a WindowPane in the Echo2 framework. The result is a MDI (multiple document interface) application, where there is a menu bar along the top of the page and the various 'pages' popup as movable/resizable windows. I am currently working on producing a single-document interface page that will give people something to compare with the MDI approach.

I think the MDI interface is somewhat dated looking, although many modern desktop applications work this way.

After I complete the SDI look, I will move to developing a GWT implementation workflow.

echo2

echo2 es una nueva versión del Framework Web Echo, una plataforma para desarrollar aplicaciones basadas en web que se aproximen a los clientes ricos. La versión 2.0 se mantiene fiel a los conceptos de Echo a la vez que proporciona una considerable mejora en el rendimiento y la experiencia del usuario gracias a su nuevo motor basado en Ajax.

Echo es un framework para el desarrollo de aplicaciones Web orientado a objetos y basado en eventos. Los frameworks de aplicaciones Web tradicionales siguen la orientación a página natural de interacciones HTTP, que puede ser muy incómoda para aplicaciones muy interactivas u orientadas a datos. Echo le abstrae de la naturaleza de petición-respuesta de HTTP y le permite centrarse en las interacciones de su aplicación utilizando los paradigmas de orientación a objetos y control de eventos habituales en la mayoría de tecnologías de cliente-rico. Gracias a la abstracción proporcionada por Echo, no necesita nococer HTML, HTTP, o JavaScript. Las aplicaciones se pueden instalar en cualquier contenedor de servlets Java. echo2, como su predecesor, es software de código abierto distribuido bajo los términos de la Mozilla Public License (o, si se prefiere, la GNU LGPL License).

Los interfaces de usuario de Echo están compuestos por componentes reutilizables que le permiten controlar la estructura de la página y sus interacciones. La aproximación a orientación a componentes es muy similar a la que se encuentra en otras tecnologías de interfaz utilizadas en otros entornos orientados a objetos, como el Swing de Java o el VisualBasic de Microsoft.

EchoStudio 2

EchoStudio 2.0 es un plugin para la herramienta de desarrollo rápido de aplicaciones Eclipse 3.1 capaz de crear aplicaciones basadas en web que funcionan y se comportan como clientes ricos. Apoyándose en el Framework de código abierto echo2, EchoStudio ofrece herramientas fáciles de utilizar que permiten a los desarrolladores diseñar las interfaces de usuario en menos tiempo.

Las licencias de EchoStucio incluyen la actualización gratuita durante un año a las nuevas versiones del producto (las versiones de correcciones de errores están exentas del límite de un año).

El tipo de licencia utilizado es la licencia por desarrollador, modelo en el que simplemente se adquiere una licencia para cada desarrollador que utilice EchoStudio (1 licencia $499, 5 licencias $2199, 10 licencias $3899, 25 licencias $7999).

No es necesaria ninguna licencia de tiempo de ejecución. El software que se desarrolla utilizando EchoStudio se basa en la plataforma de código abierto Echo, y por tanto se puede distribuir libre de Royalties.