Restrictions / inconvénients du développement de portlets pour Liferay [fermé]

Question

J'envisage de développer une application sous forme de portlets, à intégrer au portail Liferay. Existe-t-il des inconvénients ou des restrictions significatifs dans le développement d'une telle application, par opposition au développement d'une application Web normale utilisant le framework Spring?

Liferay semble exiger que tout le contenu soit ajouté en tant que portlets. Une autre option à laquelle je pense consiste à utiliser Liferay uniquement pour certaines parties de l'application et à ajouter des liens externes vers d'autres contenus développés par l'utilisateur, développés comme une application Web normale. Cela créerait cependant un besoin de mécanismes d’authentification par plusieurs utilisateurs et d’une sorte d’authentification entre sites entre Liferay et l’autre application Web.

Quelle est la meilleure voie à suivre?

Answer 1

(Avertissement: je suis l'un des développeurs de Liferay)

Je pense que les deux options sont bonnes en fonction de vos besoins. Si vous avez déjà développé des applications Web autonomes, mais aucune expérience en développement de portlets, le choix de l'ancien vous permettra de démarrer plus rapidement. Les inconvénients seraient que vous auriez à implémenter vos propres utilisateurs et système d'autorisations et que vous ne seriez pas en mesure de tirer parti des services de portail fournis par Liferay. Si vous décidez d'utiliser cette alternative, notez que vous pouvez déployer des fichiers WAR normaux sur Liferay et qu'il créera automatiquement un simple portlet utilisant un iframe pour afficher votre application. Cela vous permettra de mettre l'application autonome avec les portlets dans les pages de Liferay.

Le développement d’un portlet pour Liferay commence à porter ses fruits lorsque vous commencez à tirer parti des services de portail qu’il fournit. Pour commencer par développer un portlet, vous pouvez oublier de développer votre propre système utilisateur et utiliser celui fourni par Liferay (qui est assez puissant). Vous pouvez également utiliser d'autres services tels que les autorisations, les commentaires, le balisage, la catégorisation, l'étendue des données, etc., ce qui vous permettra de développer une application assez complète dans un délai plus court. L'inconvénient est que la première fois, vous devrez apprendre plusieurs nouvelles choses, mais la deuxième fois, vous irez beaucoup plus vite.

J'espère que cela aide.

Answer 2

J'utilise Liferay depuis environ 2 ans maintenant pour une application interne. Nous avons eu la même discussion à plusieurs reprises au cours du cycle de développement avant notre première publication. Nous avons dû combattre Liferay à quelques reprises, parfois à cause de notre manque de connaissances, parfois à cause de l'environnement du portlet et parfois à cause de Liferay.

Si vous voulez les options de disposition pour plusieurs applications que vous pouvez obtenir depuis un portail, vous devriez certainement utiliser Liferay. Si vous écrivez une seule application, je n’utiliserais probablement pas Liferay. Je pense qu’un hybride de Liferay et d’autres non est de loin la pire option.

Nous n'utilisons probablement pas Liferay au maximum de ses possibilités, mais s'il s'agit de votre première application Liferay, il est fort probable que vous ne le ferez pas non plus à cause de la courbe d'apprentissage. Au départ, nous espérions avoir de nombreux portlets pour les différents aspects de notre application, mais en raison du manque de bons mécanismes de communication entre les portlets au cours du développement (pré-JSR-286), nous avons fini par écrire une seule application. Maintenant que nous nous sommes retrouvés dans ce bateau, j'aurais aimé rester sans Liferay, car nous n'utilisons que des fonctionnalités de gestion des utilisateurs.

Nous utilisons JSF et facelets (les deux nouvelles technologies, la douleur a peut-être été prise en compte par nous-mêmes) et, même si nous nous sommes améliorés, il semble que nous ayons dû franchir quelques obstacles pour franchir les étapes suivantes: faites-le fonctionner correctement dans un portlet; Des choses qui n'auraient pas dû se produire dans un environnement d'applications Web normal. Pour de nombreux frameworks, il semble que la prise en charge des portlets est une réflexion après coup. Ce n'est évidemment pas spécifique à Liferay, c'est simplement un sous-produit de l'environnement de portlet.

Dans une application Web utilisant Spring MVC, Struts, Faces, Wicket, peu importe, vous aurez beaucoup plus de contrôle sur tout, mais vous serez également responsable de la mise en œuvre de plusieurs éléments.

Dans un portlet, vous allez être soumis aux conditions de JSR-168 et / ou JSR-286. Le conteneur de portail vous fournira certaines fonctionnalités, telles que l'authentification d'utilisateur, mais OMI, tout un portail pour l'authentification d'utilisateur est beaucoup trop lourd. Je vois que la puissance du portail permet à l'utilisateur de personnaliser l'affichage de plusieurs applications sans présenter une seule application.

Vous devriez consulter les spécifications relatives au portlet et voir si elles répondent à vos besoins.

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

Answer 3

Liferay est un système extrêmement puissant. De nombreux services et applications sont disponibles, prêts à être utilisés, mais le principal inconvénient est le manque de documentation. Il est impossible de tout savoir en regardant le code. Donc, à mon avis, si vous ne possédez pas l'expertise dont vous avez besoin, n'allez pas pour Liferay.

Answer 4

Liferay et les portlets en général conviennent parfaitement à une classe d'applications très spécifique. Si vous travaillez pour un service informatique et que vous avez besoin de combiner des applications pour ou par plusieurs services, utilisez des portlets. En théorie, vous pouvez déposer des portlets provenant de différents fournisseurs et ils vivront tous en harmonie dans le même environnement.

Cependant, si vous créez une application qui correspond à l'un des éléments suivants

1) entièrement créé par une seule équipe 2) a une source unique pour les besoins 3) a des exigences qui ne sont pas un sous-ensemble des fonctionnalités disponibles dans le conteneur de portlets. 4) a un graphiste qui ne veut pas vivre dans les applications de style portail.

alors rester avec quelque chose comme le printemps serait la voie à suivre.

Spring et ses nombreux sous-projets fournissent de nombreux services et infrastructures partagés offerts par les portlets, mais ils sont proposés de manière ouverte et plus flexible. Vous pouvez choisir ce que vous voulez.

Les portlets prennent en charge de nombreuses décisions de conception en termes d'authentification et d'autorisation, de navigation et de présentation. Si les plans que vous avez pour votre application ne relèvent pas de ces décisions, vous passerez beaucoup de temps à créer des solutions de contournement pour essayer de le faire faire ce que vous voulez.

Answer 5

Tout le monde, s'il vous plaît, ne prenez pas cela comme une traîne / une flamme. C’est quelque chose que la communauté de Liferay devrait aborder et que tout le monde qui envisage d’utiliser Liferay devrait savoir.

Inconvénient: pas de documentation. Rien de comparable, par exemple, à la documentation d’Hibernate. Juste un javadock vide (aucun commentaire dans le code), certains ont répondu aux questions sur les forums et des livres pour les anciennes versions (inutile).

Answer 6

J'ai toujours pensé que des portails tels que Liferay devraient être considérés comme s'apparentant à une infrastructure partagée. Ils fournissent un moyen commun d’accéder aux applications, aux services partagés (par exemple, l’authentification) et un moyen standard de déploiement, mais au détriment des performances.

Si vous avez l'intention de déployer plus que cette application sur le portail, alors oui, c'est probablement approprié, car vous obtiendrez des économies de temps et d'argent en évitant de devoir développer ces services partagés une seconde fois. Et les applications suivantes ressembleront et se comporteront de la même manière que celle-ci.

Toutefois, s'il s'agit de la seule application à être déployée, les frais généraux du portail n'en valent pas vraiment la peine et vous feriez mieux d'utiliser une application Web normale.

Answer 7

Liferay a une fonctionnalité CMS et peut s’intégrer à des plates-formes CMS externes telles que Alfresco.

Answer 8

Homme, regardez cette solution Netbeans IDE + plugin PoralPack3.0 + bundle Liferay 5.2. Portal Pack vous aide ici en fournissant un éditeur graphique convivial pour le fichier service.xml, dans lequel vous pouvez définir les entités ou les structures de base de données, et à partir de la même interface graphique, vous pouvez générer le code de services pouvant être utilisé dans votre portlet.

Pour plus d'informations, consultez le lien ci-dessous: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in