Showing posts with label portlets. Show all posts
Showing posts with label portlets. Show all posts

04 March 2011

ADF Taskflows vs ADF Portlets - Resumen

Hace unos días inicie una serie de posts, donde comparaba los pros y contras de dos alternativas de desarrollo sobre Oracle WebCenter, he aquí una recopilación de todos los enlaces.
  1. Introducción
  2. Standards
  3. Seguridad
  4. Renderización
  5. Despliegues y Re-despliegues
  6. Custom WebCenter Applications
  7. Look and Feel
  8. Preferences
  9. Reutilización

Críticas
Finalmente como crítica al modelo de desarrollo en WebCenter, los portlets desplegados en el mismo servidor que las custom webcenter aplications no deberian ser accedidos por WSRP (al menos por temas de rendimiento), siguiendo, por ejemplo, el modelo de los EJBs locales.

Enlaces relacionados:

- FIN -

03 March 2011

ADF Taskflows vs ADF Portlets - Reutilización

Por su naturaleza un portlet se puede utilizar entre múltiples aplicaciones y no necesita residir en el mismo servidor JEE de la aplicación que lo consume, mientras que un taskflow debe residir dentro de la aplicación o al menos en el mismo servidor JEE y no es de naturaleza compartida, a menos que este desplegado dentro de una “shared library”.

- FIN -

23 February 2011

ADF Taskflows vs ADF Portlets - Preferences

Los portlets pueden almacenar las preferencias del usuario para personalizar su comportamiento o características.

Esto no se puede con los taskflows (cuando estan dentro de una aplicación JEE), ya que abría que implementarlo teniendo en cuenta la gestión de instancias o utilizando algún otro mecanismo.

Jaime Cid :
Cuando los taskflows corren en WebCenter, el contenedor de WebCenter si que es capaz de admitir personalizacion y preferencias, guardadas en el MDS (digamos que los taskflows pueden correr dentro de WebCenter o correr aislados dentro de una aplicacion J2EE)

Continuará ...

- FIN -

22 February 2011

ADF Taskflows vs ADF Portlets - Look and Feel

Es complicado mantener un estilo coherente con distintos productores de portlets; como mínimo se han de duplicar las hojas de estilo en todos los portlets que consuma nuestra aplicación, con el consiguiente problema de mantenimiento.

Sin embargo los taskflows heredan los de la aplicación que los utiliza.

Continuará ...

- FIN -

17 February 2011

ADF Taskflows vs ADF Portlets - Custom WebCenter Applications

Actualmente, al contrario de otros modelos de desarrollo de portales, como por ejemplo Liferay, dentro de webcenter no residen los portlets desplegados, webcenter actúa como portlet consumer, es decir que todo portlet referenciado se consume remotamente usando el protocolo WSRP lo cual tiene cierto coste ya que se hace una llamada remota inclusive estando dentro del mismo servidor, la solución para simular "portlets locales" es usar "ADF taskflows".

Continuará ...

- FIN -

16 February 2011

ADF Taskflows vs ADF Portlets - Despliegues y Re-despliegues

En el caso de los portlets, solo se necesita registrar el productor WSRP con el EM en el servidor weblogic, por tanto no es necesario re-desplegar la aplicación para consumir la nueva funcionalidad. El catalogo de recursos se actualizará automáticamente con los productores registrados con el EM.

Cuando se usan ADF taskflows, el proceso de despliegue da un poco mas de trabajo que los portlets. Si se elige desarrollar con taskflows, estos se han de añadir como una libreria a la aplicación que los consuma, editar el catalogo de recursos y redesplegar la aplicación, aunque existe la opción de crear las librerias ADF taskflows como shared libraries (al menos para evitar los redespliegues en el caso de las actualizaciones).

Continuará ...

- FIN -

14 February 2011

ADF Taskflows vs ADF Portlets - Renderización


Rendering ADF portlets

Existe una gran diferencia entre la renderización de portlets y los taskflows.
Los taskflows se renderizan dentro de la página, mientras que los ADF portlets usan iframes.

En el caso de los portlets, la desventaja mas característica es que cuando estos lanzan un popup, este se renderiza dentro del iframe, mientras que con los taskflows no, ya que forman parte de la página.

Cada vez que se pone un portlet en una página, sus dimensiones no cambian, por ejemplo si se usa un acordeón y se despliega un panel, el portlet no se adapta a su contenido (no crece / no se redimensiona), pudiendose ver las scrollbars para mostrar el contenido, y esto desde luego no es usable. Por esta razón hay que tener cuidado al diseñar un portlet ADF.

Continuará ...

- FIN -

11 February 2011

ADF Taskflows vs ADF Portlets - Seguridad


Seguridad

Los portlets son pequeñas aplicaciones en que se ponen en un portal y por su naturaleza no es posible pasarles el securityContext desde un portal personalizado (Custom WebCenter application) que los consume, sin embargo usando taskflows, el securityContext de la aplicación esta disponible, siendo posible verificar fácilmente si un usuario tiene un rol específico o no (con ADF Security).


Este es un aspecto importantísimo a tener en cuenta si nuestros portlets se han de comportar de una manera, u otra, en base al usuario logado en el portal, y este requerimiento precisamente puede afectar al diseño de la aplicación a construir.

La JSR 168 describe que se pueden pasar roles J2EE desde una aplicación personalizada al portlet, pero las aplicaciones ADF y webcenter no usan los roles J2EE en el modelo de seguridad, así que cuando se intentan pasar los roles según la JSR, no es posible utilizarlos.

Continuará ...

- FIN -

10 February 2011

ADF Taskflows vs ADF Portlets - Standards


Standards

Los portlets se basan en standards (JSR 168/286) y se despliegan en portales JEE, lo cual "teóricamente" nos aísla de un servidor de aplicaciones concreto.

Los taskflows de ADF son (trivializando) agrupaciones de páginas y funciones que trabajan como una unidad, pero que residen dentro de una webapp.

En todo caso los ADF Taskflows se pueden publicar como portlets de forma sencilla (mediante Portlet Bridge el cual permite transformarlos en Portlets, dando la opción que los taskflows puedan ser consumidos por WSRP).

Continuará ...

- FIN -

09 February 2011

ADF Taskflows vs ADF Portlets - Introducción

Este post se centra en el desarrollo de portales con WebCenter y las dos principales alternativas de desarrollo que existen, por tanto las consideraciones aqui mencionadas se basan en este contexto.

Una de las nuevas características de ADF 11g son los taskflows, estos permiten encapsular determina funcionalidad como una unidad auto contenida, que contiene sus propias páginas, su propia navegación, control de transacciones, parámetros de entrada y de salida, se pueden invocar métodos directamente; es decir nos permite diseñar aplicaciones mucho mas modulares (a manera de componentes). Concepto bastante similar a los "page flows" de beehive.

Los portlets, se basan en standards(JSR 168 y JSR 286) y son diseñados para residir en portales JEE.

Oracle WebCenter ofrece soporte para la JSR 286 a partir de Patch Set 3; aunque para dar soporte a la IPC en la JSR 168 tiene una implementación propia.

Cuando se edita una página en WebCenter y se usa "Oracle Composer" es necesario saber que existe un catalogo de recursos, el cual contiene todos los recursos que se pueden añadir a la página, en este catalogo figuran tanto "portlets" como "taskflows".

Entonces para construir páginas en tiempo de ejecución se pueden usar tanto "portlets" como "taskflows", pero aquí es donde empieza la gran pregunta:

¿Cuando usar ADF taskflows o cuando usar ADF portlets?

Básicamente es una decisión que se basa en el contexto de la aplicación a desarrollar (requisitos), pero es importante tener en cuenta sus diferencias en el momento de la elección, en los siguientes post haré referencia a:

  • Estándares soportados
  • Preferencias de usuario
  • Seguridad
  • Look and Feel (estilos)
  • Renderización
  • Despliegues y re-despliegues
  • Custom Webcenter applications
  • Re-utilización

Continuará ...

- FIN -

28 September 2010

Desplegando con diferentes ficheros de configuración

Continuando con la cruzada maven + liferay....

Bueno, muchas veces, cuando desarrollamos, atacamos nuestra propia base de datos y utilizamos ficheros de propiedades para almacenar algunos de los parametros variables de la aplicación, evidentemente con las rutas y puertos de nuestra máquina; ahora bien, cuando desplegamos nuestra aplicación, en otro entorno que no sea el de desarrollo local, se nos presenta el problema de tener que modificar el paquete (jar, war, ear), con el fin de actualizar los valores de las propiedades, con aquellos correspondientes al entorno de destino.

Esto es algo que se puede controlar fácilmente, si utilizamos ANT o MAVEN.  En el caso de MAVEN, este dispone de un elemento llamado PROFILE y de un plugin llamado maven-antrun-plugin, cuya combinación nos permite generar los desplegables adecuados al entorno de destino de una forma fácil.

Pues bien el secreto de la receta se basa en:
  1. Tener tantos ficheros de propiedades como entornos de destino vayamos a tener ( config.properties, config.int.properties, config.pre.properties, config.pro.properties)
  2. Crear un perfil, por cada entorno de destino previsto, dentro de nuestro pom.xml, de preferencia con un nombre descritptivo, referente a su destino.
  3. Añadir el plugin maven-antrun-plugin en cada perfil para que borre los ficheros redundantes de configuración, y copie y renombre los necesarios.

He aquí un pequeño snippet de ejemplo, con "dos ficheros y un destino":

<profiles>
 ...
 <profile>
  <id>integracion</id>
  <build>
    <plugins>
       ...
 <plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
   <execution>
    <phase>compile</phase>
    <goals><goal>run</goal></goals>
 
    <configuration>
     <tasks>
      <echo>------------------------------------------------</echo>
      <echo>COPIANDO LOS FICHEROS DEL ENTORNO DE INTEGRACION</echo>
      <echo>------------------------------------------------</echo>
      <delete
       file="${project.build.outputDirectory}/config.int.properties" />
      <delete
       file="${project.build.outputDirectory}/config.properties" />
      <copy
       file="src/main/resources/config.int.properties"
       tofile="${project.build.outputDirectory}/config.properties" />
     </tasks>
    </configuration>
    
   </execution>
  </executions>
 </plugin>
       ...
    </plugins>
  </build>
 </profile>
 ...
</profiles>

En este ejemplo, en un entorno normal se utilizará el fichero config.properties por defecto, y cuando invocamos la compilación y la generación del war no se hará nada especial.
Sin embargo, si, al compilar y generar el war indicamos que se debe ejecutar el perfil llamado "integracion", este borrará todos los ficheros de configuración de los entornos innecesarios y copiará únicamente aquel que necesita, renombrandolo a fin que pueda ser accedido por el código, en tiempo de ejecución, sin más complicaciones.

InputStream is = Configuracion.class.getResourceAsStream("config.properties");
Properties tmp = new Properties();
tmp.load(is);
Evidentemente a este último código le falta algún que otro try/catch.


Enlaces relacionados:
Building For Different Environments with Maven 2


- FIN -

22 September 2010

Utilidad para transformar ficheros de internacionalización

native2ascii es una instrucción de linea de comandos que trae java, ubicado en el directorio bin, nos permite escribir ficheros de propiedades en el idioma nativo al cual se esta internacionalizando la aplicación y convertirlo en el formato de destino deseado, transformando los caracteres especiales, como por ejemplo los acentos a la codificación deseada sin necesidad de conocerla.

 
Utilizando esta herramienta evitaremos que nuestros textos se vean mal cuando se presentan, por ejemplo, en entornos web.

 
C:\jdk\bin>native2ascii -encoding UTF-8 Language_es.properties.native Language_es.properties

 
Enlaces relacionados:

 
- FIN -

30 July 2010

Creación de portlets con Struts2, Maven y Eclipse

Struts2 nos provee de una serie de arquetipos maven que aceleran nuestro proceso de desarrollo, algunos de ellos nos permiten crear portlets JSR 168.

Los arquetipos para crear portlets JSR 168 son:
  • struts2-archetype-portlet.- Para crear un portlets vacios.
  • struts2-archetype-dbportlet.- Para crear portlets que muestran el contenido de una tabla de base de datos (Consultas, Spring, HSQL, preferencias).

Para tener disponibles estos arquetipos en el repositorio maven al que esta conectado eclipse hay que añadir un arquetipo nuevo; esta opción sale cuando creamos un proyecto maven y nos pide que seleccionemos el arquetipo que deseamos utilizar.


Una vez que se levanta el popup del nuevo arquetipo, hay que introducir sus opciones de registro del arquetipo que deseamos utilizar.

Si estamos creando portlets para Liferay, después de crear el proyecto, simplemente hay que añadir los ficheros propios de configuración de este (liferay-display.xml, liferay-plugin-package.properties y liferay-portlet.xml).

Enlaces relacionados:


- FIN -

16 June 2010

Desplegar un "portlet maven" en la carpeta deploy de liferay

Desde luego desarrollar portlets o hooks liferay, utilizando eclipse con maven tiene sus ventajas (hay material para muchos post), pero uno de los contratiempos que encuentro es tener que copiar el war resultante del empaquetado, en la carpeta deploy de liferay.

Pero a grandes males, grandes remedios; así que solo tenemos que configurar el pom.xml para indicarle a maven que el directorio de salida donde se depositará el war sea la carpeta deploy de liferay.

He aquí el extracto del pom.xml que hace esto.

...
<packaging>war</packaging>
...
<build>
...
 <plugin>
  <!-- http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html  -->
  <artifactId>maven-war-plugin</artifactid>
  <configuration>
  <outputDirectory>C:/dev/liferay/deploy</outputdirectory>
  </configuration>
 </plugin>
...
</build>
...


Buen provecho!

Enlaces relacionados:
Creating Liferay portlet with liferay-maven-sdk

- FIN -

07 May 2010

Variables disponibles en las JSP de portlets

Las siguientes son las variables disponibles dentro de las JSP de los portlets según su JSR.

Para la JSR 168 (Portlet 1.0)
  • RenderRequest renderRequest
  • RenderResponse renderResponse
  • PortletConfig portletConfig
Para la JSR 268 (Portlet 2.0)  
  • Si la JSP se ha incluido desde el metodo render
    • RenderRequest renderRequest
    • RenderResponse renderResponse
  •  Si la JSP se ha incluido desde el método serveResource
    • ResourceRequest resourceRequest
    • ResourceResponse resourceResponse
  • Si la JSP se ha incluido desde el método processAction
    • ActionRequest actionRequest
    • ActionResponse actionResponse
  • Si la JSP se ha incluido desde el método processEvent
    • EventRequest eventRequest
    • EventResponse eventResponse
  • PortletConfig portletConfig
  • PortletSession portletSession (es nula si no existe la session)
  • Map portletSessionScope (permite acceder a los atributos del portletSession)
  • PortletPreferences portletPreferences (da acceso a las preferencias del portlet)
  • Map portletPreferencesValues (devuelve un Map con las preferencias del portlet)

Pero(evidentemente) para tener acceso a todos estos atributos es necesario incluir los taglibs correspodientes dentro de cada JSP donde se desee utilizarlas.

Para la JSR 168 (Portlet 1.0)
<%@ taglib uri=”http://java.sun.com/portlet” prefix=”portlet”%>
<portlet:defineObjects/>

Para la JSR 268 (Portlet 2.0)
<%@ taglib uri=”http://java.sun.com/portlet_2_0” prefix=”portlet”%>
<portlet:defineObjects/>



- FIN -

19 December 2007

This portlet is no longer available. Please remove

Sale cuando dentro del portal tenemos referencias a portlets que no están desplegados.

En este caso al hacer un publish desde bea workshop de la modificación de un controller, misteriosamente me des-instalo la aplicación que contenía los portlets.

SOLUCIÓN: volver a deployar la aplicación con los portlets.

- FIN -