java - source - liferay ultima version
Restricciones/desventajas de desarrollar portlets para Liferay (8)
(Descargo de responsabilidad: soy uno de los desarrolladores de Liferay)
Creo que ambas opciones son buenas según tus necesidades. Si tiene experiencia previa en el desarrollo de aplicaciones web independientes, pero no tiene experiencia en el desarrollo de portlets, al seleccionar el primero podrá comenzar a trabajar 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 que automáticamente creará un portlet simple que utiliza 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 utilizar otros servicios como permisos, comentarios, etiquetado, categorización, alcance de datos, etc. que le permitirán desarrollar una aplicación bastante completa en menos tiempo. El inconveniente es que la primera vez que hagas esto tendrás que aprender varias cosas nuevas, pero la segunda vez irás mucho más rápido.
Espero que eso ayude.
Estoy considerando desarrollar una aplicación como portlets, para integrarla 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 ir?
He estado usando Liferay durante aproximadamente 2 años para una aplicación interna. Tuvimos la misma discusión muchas veces a lo largo del ciclo de desarrollo antes de nuestro primer lanzamiento. 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 debería usar Liferay. Si está escribiendo una sola aplicación, entonces probablemente no usaría Liferay. Creo que un híbrido de algunos Liferay y otros no es, con mucho, la peor opción.
Probablemente no estemos aprovechando a Liferay a su máxima capacidad, pero si esta es su primera aplicación de 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 JSR-286), terminamos escribiendo una sola aplicación. Ahora que terminamos en ese barco, desearía que nos hubiéramos quedado sin Liferay, ya que todo lo que realmente estamos usando son algunas capacidades de administración de usuarios.
Usamos JSF y facetas (ambas tecnologías nuevas para nosotros, por lo que el dolor puede haber sido autocomplaciente) y, aunque hemos mejorado, parece que hubo algunos obstáculos que tuvimos que superar para que funcionara. correctamente en un portlet; Cosas que no hubieran tenido que suceder en un entorno de aplicación web regular. Para muchos marcos, 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 que usa 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, estará sujeto a los términos de JSR-168 y / o JSR-286. El contenedor del portal proporcionará algunas funciones para usted, como la autenticación de usuarios, pero en mi opinión, un portal completo para la autenticación de usuarios 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 ajustan a sus necesidades.
http://developers.sun.com/portalserver/reference/techart/jsr168/
Hombre, mira 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 obtener más información, consulte el siguiente enlace: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in
Liferay es un sistema extremadamente poderoso, hay muchos servicios y aplicaciones disponibles, pero el mayor inconveniente es la falta de documentación. Es imposible saber todo solo mirando el código, así que en mi opinión, si no tienes la experiencia, no vayas por Liferay.
Liferay tiene funcionalidad de CMS y puede integrarse con plataformas de CMS externas como Alfresco.
Liferay y portlets en general son geniales 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 está creando una aplicación que es cualquiera de las siguientes
1) creado completamente por un solo equipo 2) tiene una fuente única para los requisitos 3) tiene requisitos que no son un subconjunto de las características 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.
Entonces seguir con algo como la primavera sería el camino a seguir.
Spring y sus muchos subproyectos proporcionan muchos de los servicios compartidos e infraestructura que ofrecen los portlets, pero se ofrecen de una manera abierta y más flexible. Puedes escoger y elegir lo que quieras.
Los portlets toman una gran cantidad de 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.
Siempre he pensado que los portales como Liferay deben 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 una manera similar a esta.
Sin embargo, si esta es la única aplicación que se implementará, la sobrecarga del Portal realmente no vale la pena y será mejor que vaya con una aplicación web normal.
Todos, por favor no tomen esto como trolling / flaming. Esto es algo que creo que la comunidad de Liferay debería abordar y todos los que piensan usar Liferay deben saberlo.
Desventaja: Sin documentación. Nada ni remotamente como por ejemplo, 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).