Pros y contras de Java Portlets?

Question

Tengo un proyecto en el que mi cliente me pide que use las especificaciones de portlets 1.0 y Websphere Portal Server 6.0. No he trabajado con portlets antes, pero lo que he oído de ellos siempre han sido malas críticas. ¿Cuáles son las razones además de lo obvio de usarlas? Si no hay razones, ¿qué argumentos podría usar para evitarlos?

Answer 1

Los problemas que tengo con portlets me recuerdan a los mismos problemas que EJBs-

• portlets que requieren escribir código especial que sólo se puede alojar y ejecutar en un servidor especial;
• cada proveedor de servidor de portlet tiene extensiones/configuraciones/capacidades adicionales personalizadas, por lo que no es trivial cambiar los proveedores de servidores;
• portlets parecen ser demasiado complejo para cubrir la funcionalidad que el 90% de las personas que deseen utilizar, no necesitan tener

me gustaría sugerir algo así como el Google Gadgets Hibernate para portlet de EJB -

• Marco de Javascript: las piezas del lado del servidor se pueden escribir en cualquier idioma, alojadas en cualquier servidor.
• más fácil de usar
• gran cantidad de servidores de portal apoyarlo, y es más portable a través de vendedores porque no es tan complejo, y no es una especificación para los vendedores para poner en práctica (y se extienden)

Answer 2

Los portlets son atractivos para una empresa debido a la promesa de flexibilidad, permite que los clientes modifiquen y reorganicen los componentes en la página, y si usted está sirviendo principalmente contenido, entonces son un medio efectivo de hacerlo.

En mi opinión, los portales son adecuados para agregar portlets que son de contenido puro, funcionalmente independientes o simplemente relacionados (por ejemplo, cuando selecciona un elemento de una lista en un portlet, actualiza otro para mostrar los detalles). Los portlets también pueden permitir la reutilización, ya que puede configurarlos en varias páginas/ubicaciones de forma bastante simple.

Donde los problemas pueden comenzar es cuando está tratando de descomponer funciones de negocio complejas con múltiples pasos e interacciones. En este escenario, determinar la granularidad de los portlets es más un arte que una ciencia, y se debe considerar cuidadosamente las interacciones entre los portlets.

También debe tener en cuenta la flexibilidad de la interfaz de usuario. Si tiene un conjunto de bloques de construcción de portlets, su empresa debe tener claro que pueden reorganizar esos bloques, pero mover elementos entre portlets implica una reescritura. Por ejemplo, mover el botón de enviar de un portlet a la parte inferior de la página no es trivial.

Por lo tanto, en resumen, supongo que depende de lo que está tratando de hacer y la cantidad de reutilización que anticipa de los componentes. Puede ser más simple administrar la reutilización creando componentes técnicos que IT compila en servlets, o puede ser que los portlets sean perfectos para su negocio. No hay una respuesta correcta, solo debes considerar cuidadosamente lo que estás tratando de lograr. Si decide los portlets, necesita abarcar todo el ciclo de vida y evitar la tentación de evitarlos, puede encontrarse rápidamente en un mal lugar con todos los gastos generales y las restricciones de los portlets, sin poder darse cuenta de las ventajas.

Answer 3

Como alguien que ha tenido varios trabajos (incluido mi actual) desarrollando portlets de Java, yo diría que no los use.

aquí está el problema:

Si sólo desea utilizar el preexistente funcionalidad del portal que está eligiendo, a continuación, utilizar un portal.

Si su uso de portlets es solo para construir un tablero pequeño, liviano, principalmente de solo lectura basado en web, donde puede ver rápidamente información dispar, entonces está bien.

Pero si usted (o más probablemente alguien más arriba en el organigrama) piensa en portlets como una forma de poner un montón de diferentes aplicaciones web en una página y tener todo "solo funciona", entonces se dirige hacia un mundo de dolor Los portlets son islas de funcionalidad altamente restringidas e independientes, no aplicaciones web en pequeños cuadrados en una página.

Cada uno de mis trabajos basados ​​en portlet ha cometido este error, y no hay luz al final del túnel. Como desarrollador de portlets, he aquí una pequeña lista de las cosas que está acostumbrado a hacerlo en aplicaciones web normales, que no se puede hacer de forma fiable en portlets:

• generar URL a otras páginas. Necesitará una forma específica de proveedor para hacerlo, ya que la API de Portlet solo le permite generar URL que se dirigen al portlet que los generó.
• Lea y configure los encabezados HTTP o establezca el código de respuesta HTTP (para que no haya redirecciones o caché HTTP, ya que no posee la página en la que se colocará su portlet)
• Tener que nombrar todos los identificadores en la página generada. Esto significa atributos de id HTML y nombres de funciones de JavaScript. Dado que el espacio de nombres debe determinarse en tiempo de ejecución para garantizar la exclusividad, no puede hacer que estas funciones de Javascript residan en un archivo de caché independiente del navegador, sino en el cuerpo de respuesta de su portlet.

Los portlets se sienten como si estuvieran diseñados para el estado del desarrollo web como a mediados y finales de los 90 (pre-AJAX). Pero no son adecuados para los entornos actuales de desarrollo web (AJAX, aplicaciones web enriquecidas de una sola página, etc.) que asumen que tiene el control completo del ciclo de solicitud/respuesta.