Pro und Kontra von Java Portlets?

Question

Ich habe ein Projekt, in dem mein Client mich fragt, Portlets 1.0 Spezifikation und Websphere Portal Server 6.0 zu verwenden. Ich habe noch nie mit Portlets gearbeitet, aber was ich von ihnen gehört habe, waren immer schlechte Kritiken. Was sind die Gründe neben dem offensichtlichen ihrer Verwendung? Wenn nicht Gründe, welche Argumente könnte ich verwenden, um sie zu vermeiden?

Answer 1

Die Probleme, die ich mit Portlets haben, erinnern mich an den gleichen Problemen wie EJBs-

• Portlets benötigen Sie speziellen Code zu schreiben, der nur gehostet werden können und in einem speziellen Server laufen;
• Jeder Portlet-Server-Anbieter verfügt über benutzerdefinierte Erweiterungen/Konfigurationen/zusätzliche Fähigkeiten, so dass es nicht trivial ist, Server-Anbieter zu ändern;
• Portlets scheinen zu komplex zu sein, Funktionalität abzudecken, dass 90% der Menschen wollen es nicht

Ich würde verwenden, braucht so etwas wie Google Gadgets als die Hibernate EJB Portlet -

• Javascript Framework - Server-Side-Stücke können in jeder Sprache geschrieben werden, gehostet auf jedem Server.
• einfacher
• viele Portalserver es unterstützen zu verwenden, und es ist mehr tragbar für Anbieter, weil es nicht so komplex ist, und es ist nicht eine Spezifikation für Anbieter (und erweitert) zu implementieren

Answer 2

Portlets sind attraktiv für ein Unternehmen, weil sie Flexibilität versprechen. Sie ermöglichen es den Kunden, Komponenten auf der Seite zu optimieren und neu anzuordnen. Wenn Sie primär Inhalte bereitstellen, sind sie ein effektives Mittel dafür.

Portale sind meiner Meinung nach gut geeignet, um Portlets zu aggregieren, die entweder reiner Inhalt, funktional unabhängig oder einfach verwandt sind (wenn Sie beispielsweise ein Element aus einer Liste in einem Portlet auswählen, aktualisieren Sie ein anderes, um die Details anzuzeigen). Portlets können auch die Wiederverwendung aktivieren, da Sie sie relativ einfach in mehrere Seiten/Standorte konfigurieren können.

Die Probleme können beginnen, wenn Sie versuchen, komplexe Geschäftsfunktionen mit mehreren Schritten und Interaktionen zu zerlegen. In diesem Szenario ist die Granularität der Portlets eher eine Kunst als eine Wissenschaft, und die Interaktionen zwischen den Portlets müssen sorgfältig bedacht werden.

Sie müssen auch die Flexibilität der Benutzeroberfläche berücksichtigen. Wenn Sie über eine Reihe von Portlet-Bausteinen verfügen, muss Ihrem Unternehmen klar sein, dass sie diese Blöcke neu anordnen können, aber das Verschieben von Elementen zwischen Portlets erfordert ein Neuschreiben. Beispielsweise ist es nicht trivial, die Übergabeschaltfläche von einem Portlet zum Ende der Seite zu verschieben.

Also zusammen, ich denke, es hängt davon ab, was Sie versuchen zu tun und wie viel Wiederverwendung Sie von den Komponenten erwarten. Es ist möglicherweise einfacher, die Wiederverwendung zu verwalten, indem Sie technische Komponenten erstellen, die IT in Servlets einbaut, oder Portlets sind möglicherweise perfekt für Ihr Unternehmen. Es gibt keine richtige Antwort, Sie müssen nur sorgfältig überlegen, was Sie erreichen möchten. Wenn Sie sich für Portlets entscheiden, müssen Sie den gesamten Lebenszyklus berücksichtigen und jede Versuchung vermeiden, sie zu umgehen. Sie können sich schnell mit allen Gemeinkosten und Einschränkungen von Portlets an einem schlechten Ort wiederfinden, ohne die Vorteile realisieren zu können.

Answer 3

Als jemand, hatte mehrere Jobs (einschließlich meiner aktuellen) Java-Portlets zu entwickeln, würde ich sagen, verwende sie nicht.

Hier ist das Problem:

Wenn Sie nur die bereits vorhandene Funktionalität des Portals Sie entscheiden, dann verwenden Sie ein Portal nutzen wollte.

Wenn Sie Portlets verwenden, um ein kleines, leichtes, in erster Linie schreibgeschütztes webbasiertes Dashboard zu erstellen, in dem Sie schnell verschiedene Informationen anzeigen können, ist das in Ordnung.

Aber wenn Sie (oder eher jemand, der weiter oben im Organigramm ist) Portlets als eine Möglichkeit ansieht, eine Reihe verschiedener Web-Apps auf einer Seite zu speichern und alles "nur funktionieren", dann sind Sie unterwegs eine Welt der Verletzung. Portlets sind stark eingeschränkte, in sich geschlossene Funktionsinseln, keine Web-Apps in winzigen Quadraten auf einer Seite.

Jeder meiner Portlet-basierte Jobs hat diesen Fehler gemacht, und es gibt kein Licht am Ende des Tunnels. Als Portlet-Entwickler erhalten Sie hier eine kleine Liste von Dingen, die Sie in regulären Web-Apps gewohnt sind, die Sie in Portlets nicht zuverlässig ausführen können:

URLs zu anderen Seiten generieren. Sie benötigen dazu eine herstellerspezifische Vorgehensweise, da Sie mit der Portlet-API nur URLs generieren können, die auf das Portlet ausgerichtet sind, von dem sie generiert wurden.

Lesen und setzen Sie HTTP-Header oder setzen Sie den HTTP-Antwortcode (also keine Weiterleitungen oder HTTP-Caching, da Sie nicht die Seite besitzen, auf der Ihr Portlet platziert wird)

Namespace alle Bezeichner in der generierten Seite. Dies bedeutet HTML-ID-Attribute und JavaScript-Funktionsnamen. Da der Namespace zur Laufzeit zur Sicherstellung der Eindeutigkeit ermittelt werden muss, können diese JavaScript-Funktionen nicht in einer separaten browserfähigen Datei gespeichert werden, sondern müssen sich im Antworttext für Ihr Portlet befinden.

Portlets fühlen sich an, als ob sie für den Zustand der Webentwicklung entwickelt wurden, wie es Mitte bis Ende der 90er Jahre war (Pre-AJAX). Sie eignen sich jedoch nicht für heutige Webentwicklungsumgebungen (AJAX, einseitige Rich-Web-Anwendungen usw.), bei denen davon ausgegangen wird, dass Sie die vollständige Kontrolle über den Anfrage-/Antwortzyklus haben.