En la anterior entrega tocamos el tema del manejo de la configuración en el portal ,las estrategias para utilizar efectivamente cada una de las facilidades de los Portlets y los motivos por los cuales usar uno u otro.

En este post trataremos un tema muy delicado el cual es el manejo de la sesión de nuestra aplicación sin mas preámbulos empiezo a detallar cada una de las buenas practicas al respecto.

• Limitar el uso de la sesión del portlet. La recomendación es muy explicita para este caso no se debe de abusar del uso de la sesión, no cualquier dato debe ser almacenado en esa área. En este punto tenemos dos ejemplos el primero es el almacenar un objeto que es muy costoso en ser construido/obtenido en este caso si recomiendo que sea almacenado en sesión para que no se incurra en el costo de tener que crear un nuevo objeto por cada request (render y/o action) y el segundo caso es de un objeto que puede ser generado en cualquier momento y no implica mucho costo para el sistema (un listado de tipos de documentos) estos no tendrían por que ser almacenados en la sesión puesto que aun se puede asumir el costo de su construcción. Si eres de los que le gusta usar la sesión para todo pues es momento que analices que debe de ir o no dentro de tal forma que evitas los famosos java.lang.OutOfMemoryError.
  
• Evitar el uso de la sesión si es que el portlet puede ser accedido por anónimos. Tiene mucho sentido puesto que la sesión debe ser usada justamente cuando el usuario se ha conectado a la aplicación previa validación de usuario y contraseña. Si el portlet esta disponible para cualquier usuario eso quiere decir que la información que se muestra no es sensible por lo tanto algunos datos se podrían manejar usando campos ocultos (inputs hidden dentro del formulario). Por el momento no me ha tocado crear un portlet para usuarios anónimos pero es mas que seguro que tendré en cuenta esta recomendación para futuros desarrollos.
• Siempre usar PortletRequest.getPortletSession() para obtener una sesión valida. Hasta el momento no se como obtener una nueva sesión que no sea de esa forma pero si la hay no debería usarse puesto que se podría estar obteniendo un valor invalido.

Finalmente podemos llegar a la conclusión que el uso de la sesión debe de realizarse con mucho cuidado y siempre teniendo en cuenta algunas consideraciones previas.

Para la siguiente entrega se tocará el tema de la internacionalización el cual tiene como objetivo mostrarnos algunas sugerencias para hacer que nuestro portlet muestre contenido dependiendo del idioma del cliente.

En el anterior post tocamos el manejo de los paquetes y utilitarios (falto poner el buen diseño de los Portlets) ahora nos toca hablar del manejo de la configuración en nuestra aplicación de portal.

Para empezar tenemos tres posibles lugares donde podemos almacenar nuestra configuración estos son: la configuración de portlet, los datos del portlet y la configuración del servlet.

A continuación detallaré cada uno de estos y cuando debe ser usado:

1. Configuración del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet y este no depende del usuario que se encuentra utilizando la aplicación. Este tipo de configuración se realiza por medio del archivo portlet.xml o también usando el modo config del portlet. Ahora cuando usar este tipo, por ejemplo el cambiar el origen de datos de un portlet para una determinada pagina.
2. Datos del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet pero dependiente del usuario que se encuentra utilizando la aplicación. Esta forma de configuración puede sobreescribir los datos manejados en el primer caso y la forma de administrar estos valores es usando el modo edit del portlet. Un buen ejemplo del uso de este parámetro podría ser la personalización del tamaño de paginación en un listado por parte del usuario.
   
3. Configuración del servlet, usamos esta forma de manejo de los parametros cuando queremos incluir valores que sabemos que no van a cambiar durante todo el ciclo de vida de la aplicación dentro del contenedor. El mas claro ejemplo seria utilizar esta forma para almacenar las rutas de donde se leerán los archivos de configuración (properties, xml, imagenes, etc), para esto utilizamos el archivo web.xml .

Como podemos apreciar para configurar nuestra aplicación tenemos tres formas cada una orientada a una situación en particular lo cual podría complicar al desarrollador, claro esta siempre y cuando no se tenga en cuenta cual es el objetivo de cada una de estas formas.
El próximo post tratará sobre el manejo de la sesión este tema deberá de tocarse muy a detalle por que muchos desarrolladores abusan de su uso y al final generan los famosos "Memory Leak".

En la segunda parte de las buenas practicas para el desarrollo de portlets hablamos sobre las consideraciones a tener en cuenta sobre los jsps en esta entrega trataremos el tema de los paquetes y utilitarios como poder distribuirlos y algunas sugerencias al respecto. Debido a que el articulo solo toca dos puntos no usaré los marcadores.

Empaquetar las funcionalidades comunes a los Portlets. Suena un poco raro al momento de leerlo en ingles pero quizá esta sea una traducción adecuada ya que el objetivo del mismo el de separar las funcionalidades comunes en un jar de tal manera que pueda ser reutilizable. Ahora supongamos que tenemos dos casos (los cuales detallaré) en los que nos podemos encontrar:

1. Se tiene una aplicación en portal y se tienen componentes de la capa de acceso a datos (en adelante DAO), estos componentes son compartidos por varios portlets dentro de la misma aplicación, la pregunta es ¿Será necesario separar el DAO en un jar aparte? La respuesta es NO, si ten encuentras en esta situación deberías de pensar en el patrón KISS (y no es el grupo) ya que la casuística no posee mucha complejidad y no requiere una separación.
2. Supongamos que tienes un caso un tanto similar al anterior solo que ese componente es usado por varios Portlets de muchas otras aplicaciones, pues el escenario cambia y en este caso para tener componentes reutilizables se debería crear un jar que posea este bloque de funcionalidades y simplemente durante el desplegado solo se haga referencia al mismo. Pero repetir el jar en todas nuestras aplicaciones con toda la funcionalidad incluida no seria muy útil por que nunca falta alguien que muy hábilmente modifique el jar y lo use inadecuadamente, para este caso el portal como framework nos ofrece la facilidad de exponer servicios propios. En el contenedor de WebSphere se utiliza la interfaz PortletService la cual indica que esa implementación forma parte de un servicio del portal.

La ultima consideración es sobre la reutilización del portlet, la idea gira alrededor de combinar múltiples funcionalidades dentro de un portlet único pero usando diferente configuración. Para comprender mejor la recomendación veamos algunos casos:

1. Tenemos un portlet que debe realizar una tarea administrativa sobre alguna tabla/archivo maestro esta labor incluye la búsqueda, creación, edición y eliminación de registros. Una solución propuesta para este caso es la de tener un portlet que solo muestre el listado, otro que se encargue de la modificación y creación de los registros, y finalmente un portlet que sirva para eliminar registros; esta solución propuesta se baso en que los permisos para cada una de las acciones van a depender del perfil que posea el usuario. Es muy probable que desarrollando esto aprendamos mucho sobre el manejo de wiring, la paginación de los listados, el ciclo de vida de los portlets, etc pero esta solución no es la mas adecuada ya que se están creando tres Portlets para una funcionalidad que puede ser hecha por uno solo. Ahora como se podría desarrollar, muy simple ya que las funcionalidades se deben mostrar o no dependiendo del perfil por medio del servicio de manejo de usuarios del portal obtenemos el perfil y validamos si es que se le debe o no de mostrar la funcionalidad, en caso se muestre como parte de la navegación del portal mostramos otra página y listo no tuvimos que crear mas Portlets sino que diseñamos bien uno solo que tiene todas las funcionalidades que necesitamos.
2. Nuestro segundo caso podría ser una aplicación portlet que dependiendo de la página en la que se encuentre muestre información de una fuente de datos determinada y si esta en alguna otra página se vaya a la fuente por defecto. Para este caso podríamos crear un portlet (dentro de la misma aplicación) por cada una de las fuentes de datos , si bien la solución es muy práctica no es la mas adecuada debido a que si aumentan las fuentes de datos tendríamos que crear mas Portlets lo cual nos causaría un mayor costo en cuanto a tiempo y obviamente en dinero. Una posible solución que podríamos ofrecer es la de tener un portlet que implemente el modo config y dentro de este haya un parámetro que indique la fuente de datos de origen con la cual se quiera configurar (por defecto mostrará un valor); este parámetro se va a encontrar como parte de los parámetros del contexto del portal por lo cual cada instancia del portlet puede ser configurada al antojo del administrador del portal.
3. Otro caso que podríamos encontrar es la de tener una aplicación que se encargue de buscar a los clientes de una empresa y también que muestre la información del mismo, la particularidad de este desarrollo es que la búsqueda sera usada por otras aplicaciones las cuales no necesariamente requieran el mostrar la información del cliente. Para este caso un tanto especial si se podría separar la funcionalidad puesto que la búsqueda debe mantenerse agnóstica de quien la llamo. Otro punto por el cual estas funcionalidades no deben de formar parte del mismo portlet es por que el buscador será utilizado en otro contexto en el cual no necesariamente se requiera mostrar la información del cliente.
   

Si bien este post contiene pocas buenas prácticas posee varios ejemplos en los cuales se puede aplicar o no la recomendación. El siguiente post tocará el tema del manejo de la configuración en el portal, punto al que hicimos referencia en el tercer ejemplo de la segunda recomendación.

En el post anterior se toco el tema de manejo del código al momento de desarrollar aplicaciones para portal usando el contenedor de WebSphere.

En esta oportunidad tocará hablar acerca de las recomendaciones sobre la creación, diseño y documentación de nuestros jsps. De igual forma que el post anterior listaré cada una de las buenas prácticas y también algunos comentarios sobre mi experiencia con los mismos.

• Los jsp solo deben de contener fragmentos de código html. Si no las mas importante es una de ellas y debemos de tener muy en cuenta que la vista de los Portlets son fragmentos de código html por lo tanto agregar etiquetas como html, head o body pueden causarnos problemas puesto que estas son usadas para determinar documentos completos. En un proyecto que revisé hace un tiempo el desarrollador (que era de otra empresa) había agregado las etiquetas que menciono antes y si bien mostraba algo en el IE6 en Firefox no tenia el mismo éxito lo cual nos hace pensar cual de los dos navegadores sigue las convenciones.
• Diseñar las vistas para que puedan trabajar con otros Portlets. Esta sugerencia aplica para el caso de Portlets que van a interactuar en distintas formas de diseño en una pagina de portal (una columna, dos columnas, etc) y lo que se quiere es mantener la presentación del mismo. Ahora también se debe considerar la resolución de la maquina donde se visualiza el Portlet puesto que el cliente puede pedir que la aplicación se muestre en todo el largo de la pantalla o solo en un fragmento de ella. Todo esto nos lleva a la conclusión de que el aplicar o no esta recomendación depende del requerimiento que se nos entregue y así no gastar tiempo en características que no son necesarias.
• Usar los comentarios al estilo java en vez de los html. La idea entorno a esto es que si se va a realizar algún comentario sobre alguna etiqueta o comportamiento (condicional bucle) del jsp este se haga usando la convención de comentarios para java (<% // Este es un comentario %>) y no los comentarios de html/xml (< !-- -- >). Ahora por que debemos de seguir la sugerencia es por qué el comentario estilo java no se muestra dentro del html resultado y por qué no deberíamos mostrarlo quizá por que ahí tengamos algún mensaje que solo debe ir orientado para el desarrollador y no para aquel usuario curioso que revise el código html generado.
  
• Usar las hoja de estilos del portal en vez de una especifica. La recomendación es muy clara en este caso, uno debe de utilizar el tema por defecto del portal en conjunto con su hoja de estilos y no repetir el estilo cada vez que tenga que crear un Portlet. Para utilizar esta recomendación debemos utilizar las clases css del portal por ejemplo si tenemos que poner el estilo a una etiqueta del tipo input deberíamos usar la clase wpsButtonText asi nos aseguramos que nuestros Portlets cambiaran de apariencia cuando modifiquemos el tema del portal.
• Las urls y formularios deben ser codificados con el espacio de nombres. El uso es muy practico todas las direcciones y formularios deben der ser codificadas utilizando el tag <> esta etiqueta nos brinda la funcionalidad de codificar nuestra url de tal forma que el contenedor pueda entenderla. En el caso de los formularios se debe usar el espacio de nombres (name space) del portlet para que no sea confundido con algún otro formulario.
  
• Procurar no usar pop-ups (aunque el texto decia no usarlos). El objetivo de esta recomendación es mas que todo tener cuidado con el uso de pop-ups ya que estas llamadas salen fuera del contexto del Portlet. Ahora si nuestro enlace es para una nueva ventana tener en cuenta que el atributo target debe hacer referencia a una nueva ventana.
• Utilizar los taglibs. Considero que la mayor parte de las acciones en un jsp se pueden hacer con los taglibs quizá en un caso extremo se podría usar un scriptlet, eso dependería del requerimiento.
• Tener cuidado con el uso de IFRAMEs. Ya que esta es una forma simple de agregar contenido externo al portal debemos tener en cuenta que no todos los navegadores tienen un buen manejo de los IFRAME y si el contenido es mas grande que la sección asignada este va a mostrar un scroll vertical y/u horizontal lo cual podria generar problemas con la navegación. Hazta el momento no he tenido la necesidad de mostrar IFRAMEs pero el mismo portal tiene una opción de mostrar paginas que contienen marcos ahora no se si lo que se muestra es un IFRAME o un simple FRAME.

Como se puede apreciar varias de las recomendaciones son propias de la programación en web y otras son especiales por el simple hecho de trabajar con un portal.

En el siguiente post estaré comentando acerca de dos buenas practicas sobre el empaquetado de nuestra solución.

Parte del material de lectura que me va a servir como preparación para el examen de certificación del post anterior se encuentra disponible un articulo llamado "Portlet Development Best Practices". En este escrito se podrán ver algunas buenas prácticas al momento de desarrollar con Portlets dentro del contenedor de WebSphere.

El autor resalta doce categorías en las cuales debemos mantener buenas prácticas al momento de desarrollar Portlets, a modo de revisar estos puntos haré un resumen de cada uno de ellos indicando algunas prácticas y comentarios sobre mi experiencia con estos. Con el objetivo de mostrar el mejor detalle posible haré un articulo por cada categoría de recomendaciones.

La primera categoría es sobre algunas guías al momento de codificar usando Portlets, cosas que debemos evitar y algunas en las que debemos de poner énfasis al momento del desarrollo. En esta sección podemos encontrar las siguientes consideraciones:

• Para pasar datos al jsp se debe usar un bean que este contenido en el objeto del request. Es muy importante tener en cuenta esta recomendación puesto que de esa forma estructuramos los campos que vamos a pintar dentro de nuestro jsp. Actualmente las librerías como jstl y frameworks como jsf, spring MVC, struts proveen formas de acceso a estos campos que forman parte del objeto usando declaraciones como ${formulario.descripcion} con las cuales nuestra codificación es más comprensible y elegante.
  
• Usar las facilidades de logging del portal. Si pensaban que el portal es solamente un contenedor de aplicaciones pues se equivocan también es un framework y como tal ofrece ciertas facilidades para realizar actividades muy comunes que en este caso es el logging. Particularmente prefiero usar un framework como Log4j, al final se llega al mismo objetivo: Documentar la actividad de la aplicación dentro de una bitácora.
• Adoptar buenos hábitos de documentación. Esto no solo es para aplicaciones en portal sino para cualquier tipo de aplicación y para cualquier lenguaje. Tengo que aceptarlo que por desarrollar rápido se me olvida de la documentación y siempre hago mención que el nombre método explica su funcionalidad pero por mas que parezca redundante se debe de documentar, en el caso de java usando el javadoc, ya que no todos los integrantes del proyecto pueden tener claro el objetivo de esa función, clase o interfaz.
• Usar la caché del portal. Esta recomendación busca que se aproveche el servicio de caché ofrecido por el portal en el caso de datos que sean muy complejos de obtener o de procesar. Se recomienda el no uso de la sesión pero este punto puede ser discutible pues hay datos a los cuales es mas práctico ubicarlos en la sesión, el uso o no de la misma va a depender de la situación en la que nos encontremos.
• De trabajar con struts seguir las buenas practicas del framework y aplicarlas en el desarrollo de portlets. Nunca he trabajado con Struts y creo que por el momento no lo haré. Esta sugerencia apunta a que las mismas buenas practicas usadas en la programación web con struts deben ser usadas en el desarrollo de portlets.

Como se puede apreciar en esta sección varias de las buenas prácticas para el desarrollo de aplicaciones web con java son tomadas en para el desarrollo de portlets además de agregar algunas propias del uso de un contenedor que en este caso es WebSphere Portal.

El siguiente post tendrá como objetivo mostrar algunas recomendaciones al momento de crear nuestras presentaciones (jsp), el manejo de comentarios dentro de las mismas, entre otros.

Hoy inicio la preparación para mi primer examen de certificación el cual es el "IBM WebSphere Portal 6 Application Development", si bien ya llevo trabajando con WebSphere Portal 6/6.1 desde hace dos años siempre hay cosas que aprendo en el día a día en el trabajo. En lo posible publicaré algún concepto nuevo que voy aprendiendo en estos días de preparación.