Avantages et inconvénients des portlets Java?

Les portlets sont attrayants pour une entreprise en raison de la promesse de flexibilité, vous permettez aux clients de modifier et de réorganiser des composants sur la page, et si vous servez principalement de contenu, ils constituent un moyen efficace de le faire.

Dans mes portails d'opinion conviennent bien aux portails d'agrégation d'agrégation de contenu pur, fonctionnellement indépendant ou simplement associé (par exemple lorsque vous choisissez un élément à partir d'une liste dans un portlet, vous mettez à jour une autre pour afficher les détails). Les portlets peuvent également activer la réutilisation, car vous pouvez les configurer dans plusieurs pages / emplacements assez simplement.

Lorsque les problèmes peuvent commencer, c'est lorsque vous essayez de décomposer des fonctions commerciales complexes avec plusieurs étapes et interactions. Dans ce scénario, déterminer la granularité des portlets est plus un art que la science et une attention particulière doit être accordée aux interactions entre les portlets.

Vous devez également envisager la flexibilité de l'interface utilisateur. Si vous avez un ensemble de blocs de bâtiments de portlet, votre entreprise doit être claire qu'elle peut réorganiser ces blocs, mais les articles en mouvement entre les portlets impliquent une réécriture. Par exemple, déplacer le bouton d'envoi d'un portlet vers le bas de la page n'est pas trivial.

Donc, en résumé, je suppose que cela dépend de ce que vous essayez de faire et de la quantité de réutilisation des composants. Il peut être plus simple de gérer la réutilisation en créant des composantes techniques qu'elle construites dans des servlets ou que des portlets sont parfaits pour votre entreprise. Il n'y a pas de bonne réponse, il suffit de considérer avec précaution ce que vous essayez de réaliser. Si vous décidez des portlets, vous devez adopter le cycle de vie complet et éviter toute tentation de travailler autour d'eux, vous pouvez rapidement vous retrouver dans un mauvais endroit avec tous les frais généraux et les restrictions de portefeuilles, sans pouvoir réaliser les avantages.

Les problèmes que j'ai avec des portlets me rappellent les mêmes problèmes que les EJBS-

• Portelets Vous oblige à écrire un code spécial qui ne peut être hébergé et exécuté que dans un serveur spécial;
• Chaque fournisseur de serveurs de portlet a des extensions / configurations personnalisées / des capacités supplémentaires afin que ce ne soit pas trivial de modifier les fournisseurs de serveurs;
• Les portlets semblent être trop complexes pour couvrir la fonctionnalité que 90% des personnes souhaitant l'utiliser n'ont pas besoin

  Je suggérerais quelque chose comme Google Gadgets en tant qu'hibernate à EJB du portlet -

  • Cadre JavaScript - Les pièces côté serveur peuvent être écrites dans n'importe quelle langue, hébergée sur n'importe quel serveur.
  • plus simple à utiliser
  • Beaucoup de serveurs de portail le supportent et il est plus portable entre les fournisseurs, car ce n'est pas aussi complexe, et ce n'est pas une spécification pour les fournisseurs de mettre en œuvre (et d'étendre)

Comme quelqu'un qui a eu plusieurs emplois (y compris mon actuel) développe des portlets Java, je dirais que je ne les utiliserais pas.

Voici le problème:

Si vous vouliez simplement utiliser la fonctionnalité préexistante du portail, vous choisissez, utilisez un portail.

Si votre utilisation de portlets est simplement de construire un tableau de bord Web petit, léger, principalement en lecture seule sur le Web, où vous pouvez regarder rapidement des informations disparates, alors c'est bien.

Mais si vous (ou plus susceptibles que quelqu'un soit plus haut sur le graphique Org) pense aux portlets comme moyen de mettre un groupe de différentes applications Web sur une page et de faire tout ce que vous «travaillez», alors vous êtes dirigé vers un monde de blessures. Les portlets sont des îles de fonctionnalité fortement restreintes et autonomes, et non des applications Web dans de minuscules carrés sur une page.

Chacun de mes emplois à base de portlet a fait cette erreur et il n'y a pas de lumière au bout du tunnel. En tant que développeur de portlet, voici une petite liste de choses que vous avez utilisées dans des applications Web régulières, que vous ne pouvez pas faire de manière fiable dans des portlets:

• génère des URL à d'autres pages. Vous aurez besoin d'une manière spécifique au fournisseur pour le faire, car l'API de portlet vous permet seulement de générer des URL ciblant le portlet qui les a générés.
• Lire et définir des en-têtes HTTP ou définissez le code de réponse HTTP (donc aucune redirection ni la mise en cache HTTP, car vous ne possédez pas la page que votre portlet sera placé)
• Devoir l'espace de nom de tous les identificateurs de la page générée. Cela signifie les attributs d'identification HTML et les noms de fonction JavaScript. Étant donné que l'espace de noms doit être déterminé au moment de l'exécution pour assurer l'unicité, vous ne pouvez pas disposer de ces fonctions JavaScript dans un fichier de navigateur séparé-cache-câble dont ils doivent être dans le corps de réponse de votre portlet.

  Les portlets se sentent comme si elles étaient conçues pour l'état de développement Web telle qu'elle était au milieu de la fin des années 90 (pré-Ajax). Mais ils sont mal adaptés aux environnements de développement Web d'aujourd'hui (AJAX, Applications Web riches en une seule page, etc.) qui supposent que vous disposez d'un contrôle complet du cycle de demande / de réponse.