Vor- und Nachteile von Java-Portlets?

Question

Ich habe ein Projekt, in dem mein Kunde mich auffordert, Portlets 1.0-Spezifikation und Websphere Portal Server 6.0 zu verwenden.Ich habe noch nie mit Portlets gearbeitet, aber ich habe immer nur schlechte Kritiken über sie gehört.Welche Gründe gibt es außer den offensichtlichen Gründen für deren 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 spezielle Code zu schreiben, der nur gehostet werden kann und läuft in einem speziellen Server;
• jeder Portlet-Server-Hersteller hat kundenspezifische 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 benutzen müssen

würde ich so etwas wie vorschlagen Google Gadgets als Hibernate EJB Portlet -

• JavaScript-Framework -. Serverseitige Stücke können in jeder Sprache, gehostet auf einem beliebigen Server geschrieben werden
• einfacher zu bedienen
• viele Portal-Server unterstützen es, und es ist mehr tragbar für Anbieter, weil es nicht so komplex ist, und es ist nicht eine Spezifikation für die Anbieter zu implementieren (und erweitern)

Answer 2

Als jemand, der mehrere Jobs hatte (einschließlich meiner aktuellen) die Entwicklung von Java-Portlets, würde ich nicht sagen, sie verwenden.

Hier ist das Problem:

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

Wenn Ihre Verwendung von Portlets ist nur ein kleines, leicht zu konstruieren, in erster Linie read-only web-basierte Dashboard können Sie schnell auf disparate Informationen sehen können, dann ist das in Ordnung.

Aber wenn Sie (oder eher jemand höher auf dem Organigramm up) von Portlets als so denken, eine Reihe von verschiedenen Web-Anwendungen auf einer Seite zu setzen und hat alles „einfach funktionieren“, dann sind Sie für eine Leitung World of hurt. Portlets sind Inseln Funktionalität hoch beschränkt, in sich geschlossene, nicht Web-Anwendungen in kleinen Plätzen auf einer Seite.

Jeder meiner Portlet-basierten Arbeitsplätze hat diesen Fehler gemacht, und es gibt kein Licht am Ende des Tunnels. Als Portlet-Entwickler, ist hier eine kleine Liste der Dinge, die Sie in regelmäßigen Web-Anwendungen zu tun gewohnt sind, dass Sie nicht zuverlässig in Portlets können:

• Generieren URLs zu anderen Seiten. Sie erhalten eine herstellerspezifische Art und Weise brauchen, das zu tun, da die Portlet-API können Sie nur URLs erzeugen, die das Portlet Ziel, die sie erzeugt.
• Lesen und setzen HTTP-Header oder die HTTP-Antwortcode gesetzt (also keine Umleitungen oder HTTP-Caching, da Sie nicht auf eigene Sie die Seite Ihres Portlets platziert werden)
• Nachdem alle Bezeichner in der generierten Seite Namespace. Dies bedeutet, HTML-ID-Attribute und JavaScript-Funktion Namen. Da der Namensraum zur Laufzeit bestimmt werden muss Eindeutigkeit gewährleisten, können Sie nicht diese Javascript-Funktionen in einer separaten Browser-cachable wohnen haben sie für das Portlet im Antworttext-Datei sein.

Portlets fühlen, als ob sie für den Stand der Web-Entwicklung konzipiert wurden, wie es in der Mitte bis Ende der 90er Jahre (pre-AJAX) war. Aber sie sind schlecht geeignet für Web-Entwicklungsumgebungen von heute (AJAX, Single-Seite reichen Web-Anwendungen, etc.), die annehmen, dass Sie die vollständige Kontrolle über den Request / Response-Zyklus haben.

Answer 3

Portlets sind für ein Unternehmen attraktiv, weil sie Flexibilität versprechen. Sie ermöglichen es Kunden, Komponenten auf der Seite zu optimieren und neu anzuordnen. Wenn Sie in erster Linie Inhalte bereitstellen, sind sie hierfür ein wirksames Mittel.

Meiner Meinung nach eignen sich Portale gut für die Aggregation von Portlets, die entweder reinen Inhalt haben, funktional unabhängig sind oder einfach miteinander in Zusammenhang stehen (z. B. wenn Sie in einem Portlet ein Element aus einer Liste auswählen, aktualisieren Sie ein anderes, um die Details anzuzeigen).Portlets können auch die Wiederverwendung ermöglichen, da Sie sie relativ einfach für mehrere Seiten/Standorte konfigurieren können.

Die Probleme können entstehen, wenn Sie versuchen, komplexe Geschäftsfunktionen in mehrere Schritte und Interaktionen zu zerlegen.In diesem Szenario ist die Bestimmung der Granularität der Portlets eher eine Kunst als eine Wissenschaft, und die Interaktionen zwischen den Portlets müssen sorgfältig berücksichtigt 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 es diese Blöcke neu anordnen kann. Das Verschieben von Elementen zwischen Portlets erfordert jedoch ein Umschreiben.Beispielsweise ist es nicht trivial, die Schaltfläche „Senden“ von einem Portlet an den unteren Rand der Seite zu verschieben.

Zusammenfassend denke ich, dass es davon abhängt, was Sie tun möchten und wie viel Wiederverwendung Sie von den Komponenten erwarten.Es kann einfacher sein, die Wiederverwendung zu verwalten, indem technische Komponenten erstellt werden, die die IT in Servlets einbaut, oder es kann sein, dass Portlets perfekt für Ihr Unternehmen sind.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 der Versuchung widerstehen, sie zu umgehen. Mit all dem Aufwand und den Einschränkungen von Portlets können Sie sich schnell in einer misslichen Lage wiederfinden, ohne die Vorteile erkennen zu können.