• org.jboss.seam.validationFailed : Se lanza cuando hay un fallo de validación
• org.jboss.seam.postCreate.<name> : Se lanza cuando el componente con nombre <name> se instancia. Se puede usar de forma similar a la anotación @Create de los EJBs
• org.jboss.seam.exceptionNotHandled : Se lanza cuando salta una excepción que no es manejada por Seam.
• org.jboss.seam.beforePhase y org.jboss.seam.afterPhase : Se lanzan respectivamente antes del inicio y después del final de cada fase JSF. Este evento es lanzado con el parámetro PhaseEvent, que indica la fase que empieza/acaba

La lista completa de eventos puede verse en el manual

Para escuchar eventos en Seam debemos usar la anotación @Observe para anotar un método que se ejecutará en respuesta al evento. Este método deber ser siempre público y, en el caso de los eventos predefinidos, sin argumentos (con alguna excepcion).
Hay que tener en cuenta que estos métodos se ejecutan en el mismo hilo que la traza principal, de forma que hasta que no terminen de ejecutarse la aplicación no continuará, por lo que hay que tener cuidado.

Pero aparte de los eventos predefinidos, también podemos lanzar y escuchar nuestros propios eventos.
Disponemos de varias formas de lanzar nuestros eventos personalizados:

• Etiqueta @RaiseEvent
  Al ejecutar un método anotado con la etiqueta @RaiseEvent, se lanzará el evento indicado
  1. @RaiseEvent("venta-confirmada")
  2. public String confirmarVenta(int idVenta) {
  3.   // cuerpo del metodo
  4. }

• Fichero de navegación pages.xml
  Puedes lanzar un evento mediante la etiqueta <raise-event>
  1. <navigation from-action="#{manager.confirmarVenta}">
  2.     <rule if-outcome="success">
  3.         <raise -event type="venta-confirmada" />
  4.     <redirect view-id="home"/>
  5.     </rule>
  6. </navigation>

• Mediante el componente Events
  Este componente permite lanzar eventos síncronos o asíncronos de manera programática.
  Los eventos lanzados de forma asíncrona se ejecutan en un hilo paralelo, por lo que son ideales para tareas pesadas o susceptibles de fallo que no deberían afectar al resto del sistema, como envío de emails, estadísticas...

  Las ventajas de usar esta manera de lanzar eventos es que, aparte de poder lanzar eventos asíncronos, se pueden añadir parámetros al evento, que serán pasados como argumentos a la función que los observe en el orden en el que se añaden. Por ello, la función observadora debe tener como máximo el mismo número de argumentos de los que se envían al lanzar el evento, y siempre el mismo tipo.
  También permite lanzar eventos al cabo de un determinado tiempo o lanzarlos al final de la transacción en curso.

  Aquí vemos un ejemplo que ejecuta un método a través de eventos cada vez que se confirma una venta.

  1. public String confirmarVenta(int idVenta) {
  2.     Events.instance().raiseEvent("venta-confirmada", idVenta);
  3. }
  4.  
  5. @Observe("venta-confirmada")
  6. public void observarVentaConfirmada(int idVenta) {   
  7.     // do domething
  8. }

  También podemos optar por lanzar el evento de forma asíncrona y/o añadir más parámetros al evento, los cuales serán ignorado por las funciones observadoras con menor numero de argumentos

  1. public String confirmarVenta(int idVenta) {
  2.     Events.instance().raiseEvent("venta-confirmada", idVenta, idVendedor);
  3. }
  4.  
  5. @Observe("venta-confirmada")
  6. public void registraVenta(int idVenta) {
  7.     // solo nos interesa el identificador de venta
  8. }
  9.  
  10. @Observe("venta-confirmada")
  11. public String otorgaComisionAlVendedor(int idVenta, int idVendedor) {
  12.     // Obtenemos ambos parámetros
  13. }

El primer problema con el que me topé es que mi aplicación usaba identificadores numéricos, tipo .../product.seam?idProduct=123. Por lo tanto necesitaba traducir el identificador numerico a una palabra descriptiva del producto, como .../product/silla o .../product/mesa.

Afortunadamente con Seam eso no presenta mucha dificultad y puede emplearse una EL Expression tipo #{rewriter.fromNameToId('silla')}.
Por desgracia, en el archivo urlrewrite.xml no pueden incluirse EL Expressions.

Para solucionarlo, creé una 'página virtual' en el pages.xml que recogía los parámetros como String de la url y mediante una llamada a un componente de Seam los traducía en el correspondiente identificador numérico, aprovechando que en el archivo pages.xml sí que se pueden usar EL Expressions.

• Fichero urlrewrite.xml
  1. <urlrewrite>
  2.    <rule>
  3.      <from>^/pruduct/([A-Za-z]*)$</from>
  4.      <to last="true">/virtual_product.seam?name=$1</to>
  5.    </rule>
  6.  </urlrewrite>

• Fichero pages.xml
  1. .....
  2. <page view-id="/virtual_product.xhtml" action="#{product.init}">
  3.     <param name="name"/>
  4.     <navigation>
  5.         <redirect view-id="/product.seam">   
  6.             <param name="idProduct" value="#{urlRewriter.idProductFromName(name)}"/>
  7.         </redirect>
  8.     </navigation>
  9. </page>
  10. .....

• Componente rewrite
  1. public int idProductFromName(String name) {
  2.     // Consulta en la bbdd para halar
  3.     // el id del producto a partir del nombre
  4. }

Estas URLs además de ser más intuitivas y agradables a la vista, también son más agradables para buscadores de internet como google (o podríamos decir más agradables para EL BUSCADOR de internet).Esta es una de las técnicas seo más simples, destinadas a mejorar tu posicionamiento en buscadores.

En Seam podemos obtener estas URLs sencillas a través del filtro URLrewrite. Este filtro básicamente se encarga de traducir URLs, y es muy muy fácil de usar.
Una de las principales ventajas es que es una capa independiente que se coloca por encima de la aplicación. No es necesario modificar ni una línea de código ya existente, simplemente definir cómo se van a traducir las direcciones.

1. Añadir el archivo urlrewrite.jar que viene incluido en la distribución de Seam en la carpeta WEB-INF/lib del proyecto. La mejor forma de hacerlo es mediante el archivo de ant que crea el seam-gen
2. Configurar el filtro UrlRewrite en el web.xml tal y como se indica aqui
3. Crear el fichero urlrewrite.xml que contiene las reglas de traduccion de urls en la carpeta WEB-INF. Aqui pongo el fichero del ejemplo seambay, pero lo mejor es mirar la documentacion oficial
   1. <!DOCTYPE urlrewrite
   2.     PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
   3.     "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">
   4.  
   5. <urlrewrite>
   6.  
   7.    <rule>
   8.      <from>^/feedback/([A-Za-z0-9]*)$</from>
   9.      <to last="true">/feedback.seam?member=$1</to>
   10.    </rule>
   11.    
   12.    <rule>
   13.      <from>^/itemdetail/([0-9]*)$</from>
   14.      <to last="true">/auction.seam?id=$1</to>
   15.    </rule>
   16.    
   17.    <rule>
   18.      <from>^/bidhistory/([0-9]*)$</from>
   19.      <to last="true">/bidhistory.seam?id=$1</to>
   20.    </rule>
   21.  
   22. </urlrewrite>

En otro post esplicaré con más detalle las posibilidades del fichero urlrewrite.xml, cómo usar parámetros, cómo traducir de nombres a identificadores numéricos, y cómo conseguir que las urls amigables las pueda generar nuestra aplicación tras el envío de formularios o acciones.

Siguiendo la misma idea, podemos hacer un menu contextual para las marcas, que se active al hacer click sobre ellas, y contenga acciones a ejecutar sobre la marca en cuestion.

Para ello seguiremos los siguientes pasos:

1. Crear el menu y sus acciones
2. Asignar el menu a la marca, y una referencia de la marca al menu para poder ejecutar acciones sobre ella
3. Mostrar el menu con el evento onclick y ocultarlo al seleccionar una opción

ver ejemplo

En las marcas de Google Maps este efecto puede conseguirse especificando el atributo 'title' en el constructor de la marca.

ver ejemplo

El problema es que esta opción es muy limitada, ya que se restringe al uso de texto plano. Lo ideal sería poder mostrar cualquier elemento del DOM que queramos, con su HTML y su CSS.
Para conseguirlo vamos a seguir estos pasos:

1. Crear el nodo del DOM que queramos mostrar o coger un nodo ya existente y ponerlo como un atributo de la marca
2. Al escuchar el evento mouseover de la marca, añadir el nodo al div contenedor del mapa en el la posición en la que se encuentra la marca
3. Al escuchar el evento mouseout de la marca, eliminar el nodo del div contenedor del mapa para ocultarlo.

ver ejemplo

En el caso del zoom la solución es bastante sencilla. Solo hay que sobreescribir los métodos getMinimumResolution() y getMaximumResolution() de cada uno de los tipos de mapas GMapType presentes en nuestro mapa.
Para el caso del desplazamiento, la solución es algo más compleja. Consiste en escuchar el evento move, que es lanzado por el objeto GMap cuando hay un desplazamiento, y comprobar las coordenadas del mapa tras el desplazamiento. Si estas coordenadas quedan fuera del área a la que queremos limitar el desplazamiento, usamos el metodo GMap.setCenter para que el mapa quede dentro de nuesta área.

Esta clase implementa la funcionalidad deseada:

Y aquí tenemos un ejemplo de la clase en acción

Como se puede obervar este tipo de arrays se acerca mas al concepto de Map que al de Array.
Esto ocurre porque los arrays en javascript heredan de la clase Object.
El codigo anterior seria equivalente a este:

En ambos casos podemos acceder a sus propiedades utilizando la notación de paréntesis o la notacion de puntos.

El principal problema con estos arrays viene cuando queremos iterar por ellos. Al no estar organizados por indices, no nos vale el típico "for( i=0; i Deberemos usar un "for in"

Sin embargo al iterar de esta forma no solo se enumeran las propiedades del objeto en cuestión, si no también sus funciones por lo que deberíamos hacer una comprobación de tipos mediante el operando "typeof". Este operando devuelve un String con el tipo del operador sobre el que se ejecuta.
Aqui están los resultado al ejecutar el operador "typeof" sobre cada uno de los tipos de javascript.

El tipo undefined corresponde a las variables que han sido definidas y todavía no se les ha asignado un valor.
El tipo null se suele utilizar para representar objetos que en ese momento no existen.

Sin embargo aunque son conceptos distintos el operando de igualdad los considera iguales. No así el operando typeof o el operador de igualdad estricta ===.

Si intentamos operar con una variable que tiene valor null, según el contexto devolverá los siguientes resultados.

Si intentamos operar con una variable que tiene valor undefined, según el contexto devolverá los siguientes resultados.

La idea consiste en hacer una clase que implemente el interface javax.xml.rpc.handler.Handler, capaz de interceptar los mensajes SOAP antes de su envío del cliente al servidor y antes de la recepción por parte del cliente de los mensajes enviados por el servidor.
Pueden añadirse varios handlers en serie para procesar las llamadas (handler chains). Este comportamiento es idéntico al de un ServletFilter en una cadena de filtros.
Desde esta clase tenemos acceso al contenido del mensaje SOAP, por lo que somos capaces de leerlo y escribirlo en un fichero de texto o similar.

En el caso de un cliente hecho con apache axis, podemos obtener la lista de Handlers asociados a un nombre de puerto (javax.xml.namespace.QName) y a un punto de destino a través de la clase org.apache.axis.client.Service. Una vez obtenida la lista, solo nos resta añadir nuestro Handler.

Vamos a ello. En primer lugar implementamos el interfaz javax.xml.rpc.handler.Handler para interceptar la llamada soap:

Esta clase implementa una serie de métodos extra aparte de los obligatorios definidos por el interface. Estos métodos permiten definir una lista de Streams por los que escribir el mensaje.
Estos métodos de logging deben ser invocado desde el constructor, ya que al añadir el Handler a la cadena (como veremos más adelante) no se añade una instancia de un objeto, si no una clase, y es el framework axis el encargado de crear la instancia mediante el método Class.new Instance(), por lo que no es posible definir las formas de logging si no es en el constructor por defecto del handler.

Un a vez codificada la clase, vamos a proceder a añadirla a la cadena. Cada handler debe estar asociado
Tomaremos como ejemplo un cliente WebService para Microsoft Exchange 2007, creado en un post anterior
En primer lugar buscamos la clase que extiende de org.apache.axis.client.Stub, en nuestro caso llamada ExchangeServiceBindingStub, y le añadimos dos campos para almacenar el port por el que se va a realizar la petición soap y el punto de destino.
Estos campos se van a utilizar en el metodo createCall() a la hora de crear la petición soap.
Por simplicidad crearemos los campos como públicos.

Cuando instanciamos el objeto org.apache.axis.client.Stub le añadimos el handler: