Portlet Development Best Practices (3/12) - Paquetes y Utilitarios

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.