2011-09-26 13 views
39

Estamos evaluando varias soluciones para una nueva cosa web que estamos buscando construir. Existen varios aspectos, que incluyen administración de usuarios, administración de contenido, campañas, comunidad y transacciones financieras.¿Ir o no ir con Liferay? ¿Qué es lo bueno, lo malo y lo feo?

Estamos tratando de rodar el marco nosotros mismos, utilizando Joomla + Vaadin + CAS (por nombrar algunos) para bricolaje, pero me pregunto si deberíamos simplemente adoptar el portal Liferay para compras de una sola parada?

He buscado testimonios y no he encontrado mucho. Agradezco a cualquiera que haya utilizado Liferay (o elegido no) que comparta qué obstáculos técnicos resuelve (o no) y potencialmente qué otros pueden crear.

Gracias!

+1

Joomla + Vaadin? Joomla es PHP, Vaading es Java, ¿quieres tener tanto PHP como Java para una aplicación? Eso es irrazonable. – mvmn

+0

La empresa en la que trabajo ha configurado varios proyectos diferentes Liferay independientes entre sí. Actualmente, otro grupo está trabajando en mover una página web basada en Liferay de un alojamiento externo a uno interno. Me dijeron que enfrentan muchos problemas; diferentes versiones de los portlets/librerías usados, esfuerzos para cambiar la base de datos (afaik de mysql a oracle), rompiendo los cambios entre la versión 6.0, 6.1 y 6.2 dentro de liferay estado de arreglo de fallas en la edición EE versus la edición CE. Todo esto ... – surfmuggle

+0

... me pregunto si Liferray es adecuado como base para sitios web corporativos a menos que su página sea realmente grande (digamos> 300 páginas diferentes) y cada aplicación se incorpore en una única instancia de liferay. Me gustaría escuchar su opinión y cualquier problema que enfrente al cambiar versiones y ediciones (de CE a EE). – surfmuggle

Respuesta

17

Decidimos no ir con Liferay principalmente porque no necesitábamos un servidor de portal y solo lo habríamos usado para cuestiones de seguridad. Como estábamos corriendo contra un servidor de Active Directory para mantener la información y los permisos del usuario, decidimos simplemente construir una aplicación Spring MVC y usar Spring Security para vincularla a Active Directory.

Al final, se tomó la decisión de no uso Liferay porque no queríamos que todo el exceso de carga de un contenedor de portlets cuando no necesitamos todo el material extra, y también quería mantener control total/flexibilidad sobre exactamente cómo todo estaba encadenado.

+11

No entiendo por qué se ha elegido como la mejor respuesta. La pregunta en realidad era si valía la pena utilizar Liferay como un portal o no, pero usted emitió una opinión negativa al respecto, aunque no necesitó utilizar la funcionalidad del portal. – denu

+0

@denu - Liferay _es_ un _portlet container_ y en nuestro caso, dado que no estábamos desarrollando portlets, solo se estaba utilizando para los "complementos" que otras herramientas mejoraban. El OP solicitó testimonios e información general sobre lo que hizo bien y lo que no funcionó bien. Como el OP no dijo nada acerca de tener un portal en absoluto, no estoy seguro de dónde lo estás obteniendo. Aunque estoy de acuerdo en que mi respuesta probablemente no sea la mejor. – cdeszaq

55

Descargo de responsabilidad: Trabajo para Liferay ahora; sin embargo, la respuesta se publicó mucho antes de que comenzara a trabajar aquí.

Mi empresa La empresa para la que trabajé es una socia de Liferay Inc., así que tengo mucha experiencia en ello. Además, tal vez quiera tomar mis opiniones con un grano de sal :)

Hemos utilizado varias herramientas de portal Java y la verdad es que: como portal corporativo, Liferay es el mejor en el mercado AFAIK. Es rico en funcionalidades, tiene pocos errores, su código está bien escrito, la comunidad es muy útil y flexible y personalizable, siendo útil para una amplia gama de necesidades.

Sin embargo, Liferay es una herramienta de portal, por lo que se destaca como una plataforma centrada en el contenido. Si va a administrar una gran cantidad de contenido (como noticias, artículos, blogs, wikis, foros ...), entonces felizmente recomendaría Liferay como plataforma. En otros casos, sugeriría una mejor consideración. Puede usar algo como un ERP, por ejemplo.

De todos modos, he visto a Liferay utilizado como una plataforma de desarrollo general en varios lugares y el resultado es razonable. De hecho, uno obtiene una gran mejora en la productividad cuando usa Liferay. No necesita pensar en los usuarios, permisos, gestión de contenido ... Incluso los problemas complejos de bajo nivel como la agrupación y la fragmentación pueden delegarse en Liferay. Y el Liferay Service Builder es una de las mejores herramientas de andamios para Java que he visto. Cuando lo pienso, creo que Liferay, con sus diversas aplicaciones listas para usar y su Service Builder, es como Ruby on Rails/Django para Java.

OTOH, Liferay es grande y puede ser un problema. Puede obtener un montón de cosas no utilizadas abarrotando su plataforma. Tendrás que estudiar una gran aplicación y exigirá mucho tiempo y esfuerzo de tu parte. Desafortunadamente, la documentación de Liferay es pobre, para empeorar las cosas. Como Liferay soluciona una amplia gama de problemas, su código base es grande. Esta complejidad puede ser prescindible en muchas aplicaciones, si no en la mayoría.

Además, si su aplicación no usa mucho contenido, Liferay puede proporcionar varias herramientas útiles, pero no será el entorno natural para usar Liferay. También estará encerrado en la plataforma Liferay, lo que puede restringir sus elecciones. Es posible que desee analizar las herramientas de Liferay, pero no sé si sería una buena plataforma.

En resumen, diría:

  • Si desea utilizar un portal basado en Java, o para construir un amplio portal, complejo, recomiendo Liferay sin restricciones;
  • Si desea crear una aplicación que gestione una gran cantidad de contenido, Liferay es una buena plataforma para hacerlo y creo que puede ser la mejor opción;
  • Si su aplicación es grande pero no está centrada en el contenido, no recomendaría Liferay, pero puede ser útil;
  • Si su aplicación no administra gran cantidad de contenido y es potencialmente pequeña, Liferay probablemente agregará más complejidad de la que vale.
+3

Estoy de acuerdo 100% con todo lo que dijiste. Para nuestra aplicación, está mucho más enfocado en la acción y más orientado a los datos, en lugar de estar orientado al contenido, y también es bastante pequeño. El bloqueo de la plataforma también era una preocupación, pero si tuviéramos más necesidades orientadas al portal, definitivamente habríamos seleccionado a Liferay. – cdeszaq

+3

> ... su código está bien escrito ... Consulte com.liferay.portlet.journal.service.JournalArticleLocalServiceUtil.addArticle (...). ¡¡Toma 38 parámetros !!! – FeinesFabi

+2

@FeinesFabi ¡eso es mucho parámetro, seguro! Pero hay razones para eso: esta función también se llama a través de los servicios web SOAP * y * REST que solo reciben tipos primitivos. En JavaScript, estos parámetros se pasan a través de un objeto, es mucho más claro allí. Más importante aún, este método debe ser transitorio: persiste en muchas filas y, si falla la persistencia de un objeto, debe revertir todo. Muchos parámetros fueron la solución encontrada para acomodar estos y otros requisitos. Existe un debate sobre cómo mejorarlo, pero no es un diseño ad hoc y aturdidor. – brandizzi

Cuestiones relacionadas