Restricciones/desventajas de desarrollar portlets para Liferay

Question

Estoy considerando desarrollar una aplicación como portlets, para integrar en el portal Liferay. ¿Existen desventajas o restricciones importantes en el desarrollo de dicha aplicación, en lugar de desarrollar una aplicación web normal utilizando Spring framework?

Liferay parece requerir que todo el contenido se agregue como portlets. Otra opción que considero es utilizar Liferay solo para algunas partes de la aplicación y agregar enlaces externos a otro contenido de desarrollo propio, desarrollado como una aplicación web normal. Eso, sin embargo, crearía la necesidad de múltiples mecanismos de autenticación de usuario y algún tipo de autenticación entre sitios entre Liferay y la otra aplicación web.

¿Cuál es la mejor manera de hacerlo?

Answer 1

(Negación: Soy uno de los desarrolladores de Liferay)

Creo que las dos opciones son buenas en función de sus necesidades. Si tiene experiencia previa en el desarrollo de aplicaciones web independientes pero no tiene experiencia en el desarrollo de portlets, entonces elegir el primero le ayudará a comenzar más rápido. Los inconvenientes serían que tendría que implementar sus propios usuarios y sistema de permisos y no podría aprovechar los servicios del portal provistos por Liferay. Si decide utilizar esta alternativa, tenga en cuenta que puede implementar archivos WAR normales en Liferay y creará automáticamente un portlet simple que usa un iframe para mostrar su aplicación. Esto le permitirá colocar la aplicación independiente junto con los portlets en las páginas de Liferay.

El desarrollo de un portlet para Liferay comienza a dar sus frutos cuando comienza a aprovechar los servicios del portal que proporciona. Para empezar, al desarrollar un portlet, puede olvidarse de desarrollar su propio sistema de usuario y usar el que proporciona Liferay (que es bastante poderoso). También puede usar otros servicios como permisos, comentarios, etiquetado, categorización, análisis de datos, etc. que le permitirán desarrollar aplicaciones bastante completas en menos tiempo. El inconveniente es que la primera vez que haga esto, tendrá que aprender varias cosas nuevas, pero la segunda vez irá mucho más rápido.

Espero que ayude.

Answer 2

Siempre he pensado que los portales como Liferay deberían considerarse como una infraestructura compartida. Ofrecen una forma común de acceder a aplicaciones, servicios compartidos (por ejemplo, autenticación) y una forma estándar de implementación, pero a costa del rendimiento.

Si tiene la intención de implementar más que solo esta aplicación en el Portal, sí, probablemente sea apropiado, ya que obtendrá ahorros de tiempo/costo al no tener que desarrollar esos servicios compartidos por segunda vez. Y las aplicaciones posteriores se verán y se comportarán de manera similar a esta.

Sin embargo, si esta es la única aplicación que se implementará, la sobrecarga del Portal no valdrá la pena y será mejor que vaya con una aplicación web normal.

Answer 3

Liferay tiene funcionalidad de CMS y se puede integrar con plataformas CMS externas como Alfresco.

Answer 4

He estado usando Liferay durante aproximadamente 2 años para una aplicación interna. Tuvimos la misma discusión muchas veces durante el ciclo de desarrollo antes de nuestra primera publicación. Tuvimos que pelear contra Liferay varias veces, a veces debido a nuestra propia falta de conocimiento, a veces debido al entorno de portlet, y ocasionalmente debido a Liferay.

Si desea las opciones de diseño para múltiples aplicaciones que puede obtener de un portal, entonces seguramente debe utilizar Liferay. Si está escribiendo una sola aplicación, entonces probablemente no use Liferay.Creo que un híbrido de algunos Liferay y otros no es, de lejos, la peor opción.

Probablemente no estamos aprovechando al máximo las capacidades de Liferay, pero si esta es su primera aplicación Liferay, es probable que tampoco lo haga debido a la curva de aprendizaje. Originalmente esperábamos tener muchos portlets diferentes para los diferentes aspectos de nuestra aplicación, pero debido a la falta de buenos mecanismos de comunicación entre portlets durante el desarrollo (antes de JSR-286) terminamos escribiendo una sola aplicación. Ahora que terminamos en ese bote, desearía habernos ido sin Liferay ya que todo lo que realmente estamos usando es algunas capacidades de administración de usuarios.

Utilizamos JSF y facelets (ambas nuevas tecnologías para nosotros, por lo que el dolor puede haber sido auto incrustado) y, aunque hemos mejorado, parece que hubo algunos aros que tuvimos que saltar en orden para que funcione correctamente en un portlet; Cosas que no tendrían que haber sucedido en un entorno de aplicación web regular. Para muchos frameworks, parece que el soporte de portlet es una idea de último momento. Obviamente, esto no es específico de Liferay, es solo un subproducto del trabajo en el entorno de portlet.

En una aplicación web con Spring MVC, Struts, Faces, Wicket, lo que sea, tendrás mucho más control sobre todo, pero también serás responsable de implementar más cosas.

En un portlet, usted estará sujeto a los términos de JSR-168 y/o JSR-286. El contenedor del portal le proporcionará cierta funcionalidad, como autenticación de usuario, pero IMO, un portal completo para autenticación de usuario es demasiado pesado. Veo que el poder del portal le permite al usuario personalizar su vista de múltiples aplicaciones, sin presentar una sola aplicación.

Debe revisar las especificaciones relacionadas con el portlet y ver si se ajusta a sus necesidades.

http://developers.sun.com/portalserver/reference/techart/jsr168/

Answer 5

Liferay y portlets en general son excelentes para una clase muy específica de aplicaciones. Si está trabajando para un departamento de TI y necesita combinar aplicaciones para varios departamentos, entonces los portlets serían el camino a seguir. En teoría, puede incluir portlets de diferentes vendedores y todos vivirán en armonía dentro del mismo entorno.

Sin embargo, si usted está construyendo una aplicación que es cualquiera de los siguientes

1) creada en su totalidad por un solo equipo 2) tiene una única fuente para los requisitos 3) tiene unos requisitos que no son un subconjunto de las funciones disponibles en el contenedor del portlet. 4) tiene un diseñador gráfico que no está dispuesto a vivir dentro de los límites de las aplicaciones de estilo de portal.

y luego seguir con algo como Spring sería el camino a seguir.

Spring y sus muchos subproyectos proporcionan una gran cantidad de los servicios compartidos y la infraestructura que ofrecen los portlets, pero se ofrecen de forma abierta y más flexible. Puedes escoger y elegir lo que quieras.

Los portlets toman muchas de las decisiones de diseño para usted en términos de autenticación y autorización, navegación y diseño. Si los planes que tiene para su aplicación quedan fuera de esas decisiones, pasará mucho tiempo creando soluciones para intentar que haga lo que quiera.

Answer 6

Liferay es un sistema extremadamente poderoso, hay muchos servicios y aplicaciones que están disponibles listos pero el mayor inconveniente es la falta de documentación. Es imposible saber todo simplemente mirando el código, entonces, en mi opinión, si no tienes la experiencia, no vayas por Liferay.

Answer 7

Hombre, vea esta solución Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 paquete. El Portal Pack aquí lo ayuda proporcionando un buen editor de GUI para el archivo service.xml donde puede definir las entidades o estructuras de la base de datos y desde la misma GUI puede generar el código de servicios que se puede usar dentro de su portlet.

Para más información mire el enlace a continuación se indica: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

Answer 8

Todo el mundo, por favor, no toman esto como curricán/llamas. Esto es algo que creo que la comunidad de Liferay debe abordar y todos los que piensen en usar Liferay deben saberlo.

Desventaja: Sin documentación. Nada, ni remotamente como, por ejemplo, la documentación de Hibernate. Solo un javadock vacío (sin comentarios en el código), algunas respondieron preguntas en foros y libros para versiones antiguas (inútiles).