File Upload mit JSF, Portlet und jQuery made easy and working

Im Portal, sei es nun Websphere oder Liferay oder andere funktioniert ja grundsätzlich nichts oder fast nichts  – in Bezug auf einen Fileupload -, was die Welt so (als OpenSource oder properitär) anbietet bzw. was in einer normalen Web/JSF-Anwendung grundsätzlich und gut funktioniert.

Sei es nun das native Apache Fileupload oder komplette Frontends wie die JSF-Lib Tomahawk oder jQuery.

Allerdings gibt es hier eine gar nicht zu aufwändige Alternative, die ungefähr wie folgt funktioniert (ich habe es ausprobiert, es geht).

  1. In einem Portlet includiert man in die Aufrufkette des Request über einen über PortletRequestDispatcher ein Servlet
  2. Dieses Servlet liest die über jQuery versandte Datei aus dem Request aus und wird vor dem JSF-Lifecyle aufgerufen
  3. Dazu benutzt man in diesem Servlet das Paket Apache Commons Fileupload (wie gewohnt)
  4. Den gelesenen InputStream legt man als Objekt in einem Request Attribut ab
  5. Im Portlet wieder angekommen, nach dem Ausflug zum Servlet, legt man dieses RequestAttribut in die Session oder belässt es im Request
  6. Die über den Upload Button verknüpfte (JSF)Action wird nun im JSF Cycle aufgerufen
  7. Der InputStream wird in der Action aus dem Request/der Session ausgelesen
  8. Dann kann man den InputStream, wie gewohnt, verarbeiten und z.B. in eine Datenbank schreiben

Fazit: Portlet und Servlet kann generisch und wieder verwendbar angelegt werden, so dass sich das für den JSF-Entwickler relativ seamless verwenden lässt.

Ich habe alle Freiheiten beim Upload und kann entsprechende GUI-Elemente in den JSF-Baum mischen, auch wenn es plain HTML oder jQuery z.b. ist.

Ansonsten wird in die Webanwendung nur zusätzlich ein entsprechendes und in einer Ausbaustufe generisches Servlet eingebunden.

Wer dazu Fragen hat, gerne melden.

Open Source, nicht immer der goldene Weg

Ich bin ein langjähriger Freund von Open Source, schon sehr lange und tendiere dazu , diese bevorzugt einzusetzen.

Aber auch wenn man mit Open Source viel erreichen kann und die Leistungsfähigkeit im Vergleich zu kommerziellen Produkten oft identisch ist, existieren Rahmenbedingungen, die von einem Einsatz abraten.

Die Gründe für eine Entscheidung gegen OSS sind oft nicht das Ergebnis eines direkten Vergleiches von Funktion und Kosten, sondern zu finden in der weniger komfortablen Integrationsfähigkeit in bestehende Infrastrukturen.

Und die Kosten, die man dann beim Einsatz von OSS spart, muss man anschliessend, manchmal auch mehrfach für anschliessende Integrationsleistungen aufwänden.

So z.B. im Bereich der Portalserver. Als ein intensiver Nutzer von Liferay behaupte ich, es existiert nahezu kein Grund, nicht auf Liferay zu setzen, wenn die Portalidee in einem Unternehmen eingeführt werden soll.

Ist dieses Unternehmen aber, wie z.B. viele Banken und Versicherungen, hochgradig abhängig von z.B. IBM Software wie Lotus Notes (Domino) im Bereich Email und CMS, Business Intelligence mit Cognos oder Filenet im Bereich DMS, ganz zu schweigen von ZOS als Hostbetriebssystem, dann ermöglicht der Einsatz des Websphere Portalservers eine deutlich einfachere und umfangreichere Integration.

Diese hier genannten Komponenten lassen sich auf dem visuellen Integrationslayer Portal mit Websphere sehr leicht zusammen führen. Eine Liferay Installation würde deutlich weniger Möglichkeiten – out of the Box – mitbringen.

In einem solchen Szenario machen sich die doch nicht geringen Initialinvestionen (z.B. Lizenzen) schnell bezahlt. Aber wie gesagt, hierbei ist nicht nur ein direkter Vergleich von funktionalen und nicht-funktionalen Anforderungen notwendig, sondern gerade die Enterprise Architektur Betrachtung im Unternehmen wichtig.

Wird beides vorher durchgeführt, dann ist man mit seiner Entscheidung i.d.R. auf der sicheren Seite – mit oder ohne Open Source!

Ein Euro Ajax Portal fuer IBM

Manchmal fallen mir einfach keine vernüftigen Titel (mehr) ein..?

Was ich mit diesem Blogbeitrag eigentlich beitragen möchte:

Man kann unter einer IBM Websphere Umgebung auch ein Portal nutzen, welches nicht direkt aus dem Hause IBM kommt und mit keinen hohen Initialinvestionen verbunden ist.  Ich habe jüngst das Liferay Portal auf einem IBM Websphere Application Server (6.1) und DB2 (Version 9) ohne Probleme deployen können. Wie das funktioniert, steht hier.

Wie dann eine Anwendung/Portlet unter Websphere und Liferay 5.x zu deployen ist, ist hier dokumentiert.

Und damit das dann nicht das Ende ist, kann man über das getrennt down zu loadende IceFaces-Portlet-Beispiel auch wunderbar nachvollziehen, wie man Ajax-Support (über die JSF-Bibliothek IceFaces) auch in Liferay-Portlets einbauen kann.

Auf diesem Wege erhält man nicht nur ein integrierendes Anwendungsportal in einer IBM Websphere Umgebung, sondern einen kompletten RIA Anwendungsstack – und das für einen Euro oder vielleicht auch weniger :-).

Liferay und Richfaces – zweiter Versuch

In der Zwischenzeit habe ich das Exadel-Liferay-JSF-Richfaces-Beispiel auch zum Funktionieren motivieren können, und ich muss eingestehen, wenn man sich in einem vorher abgerenzten Kontext bewegt, macht es viel Spass, mit Liferay und Richfaces zu entwickeln, Spass deswegen, weil mit wenig Aufwand schnell und viel auf der Präsentationseite einer Anwendung/eines Portlets erreicht werden kann.

Somit kann Liferay zusammen mit Richfaces m.E. zu einer echten ‚Rapid GUI Development‘-Umgebung werden.

Allerdings ist dieser sogenannte Kontext zu beachten. Dieser bedeutet heute: Laufzeitumgebung ist LR5.2+ und JBoss 4.2+. In einer Tomcat- oder anderen Runtime-Umgebung konnte ich die notwendige JBoss-Portalbridge nicht erfolgreich einsetzen.

Kontext heisst auch: Möglichst Intranet-Umgebung, eine Umgebung, in welcher der Browser vorgegeben werden kann. Denn während Richfaces und Liferay innerhalb eines Firefoxes 3+ und InternetExplorers 7+ gut funktionieren, haben andere Browser und/oder andere Versionen Probleme mit diesem Mix (z.B. Safari).

Heute würde ich aus diesem Grunde wie folgt zusammen fassen: Wenn ich Liferay auf Basis JBoss und innerhalb einer geschlossenen Umgebung einsetze, dann stellt der Einsatz von JSF Richfaces, auch in einer Portalumgebung, einen echten Mehrwert dar, für alle anderen Einsatzgebiete sollte man (noch) warten…

Allerdings sollte man noch eines bedenken: Liferay unterstützt inzwischen auch die neue Portlet-Spezifikation JSR268. Die JSF-JBoss-Portletbridge und auch JSF im Allgemeinen sind heute in Liferay nicht auf diese neuen Funktionen innerhalb des JSR268 ausgerichtet. Muss/brauche ich diese, dann ist auch wieder der Einsatz von JSF schwierig.

Liferay oder JSF, beides geht noch nicht (gut genug)

Seit einer Weile versuche ich, mehr oder weniger erfolglos, zusätzliche JSF-Bibliotheken, wie z.b. Icefaces oder RichFaces mit einem Liferay-Portal zu „verheiraten“.

Ein „bisschen“ funktionieren solche Versuche auch, aber nie so, dass ich einen Produktiveinsatz empfehlen würde und könnte.

Gestern hat dann die Firma Exadel per Newsletter mitgeteilt, dass Sie erfolgreich Liferay in der aktuellen Version (5.2.x) und Richfaces (3.3..x) zusammen zum Einsatz bringen konnten und stellen nun auch ein Downloadbeispiel zur Verfügung.

Dieses habe ich installiert, aber leider nur mit mässigem Erfolg. Die Willkommensseite inklusive der Richfaces-Tags wird in einem Liferay-Portal angezeigt, allerdings „wirft“ das System Fehler, sobald andere Links annavigiert werden.

Also auch hier leider noch keine Entwarnung in Bezug auf Richfaces und Liferay. Den Kollegen von Exadel habe ich meine Fehlermeldung mitgeteilt, in der Hoffnung, hier bald eine neue Beispielversion zu erhalten.

Richfaces ist leider zu gut, als dasss man darauf langfristig verzichten möchte. Im Zweifelsfall sollte man dann eher einen/den Portaleinsatz überdenken.

Inter Portlet Kommunikation oder die neue Art im Web zu kommunizieren

Wenn etwas wirklich interessant ist an der neuen Java Portlet 2.0 Spezifikation (JSR268) dann sind es die neuen Möglichkeiten, wie Portlets miteinander kommunizieren. In der Vergangenheit (Portlet 1.0 oder JSR168) musste man properitäre Wege beschreiten, Ähnliches zu erreichen, z.B. über Requestparameter.

ipc

Anbei ein Beispiel (eine IPC-Testanwendung von Sun) für das neue Liferay-Portal (> 5.2.x) angepasst. Liferay unterstützt bereits JSR268, wie dieses Beispiel eindrucksvoll demonstriert.

In diesem kommunzieren drei verschiedene Portlets miteinander. Auf einer Map klickt man auf einer Weltkarte einen Kontinent an und in den beiden anderen, oberen Portlets werden der Kontinent und eine Beschreibung zu diesem angezeigt. In dem verlinkten War-File ist auch der entsprechende Code inkludiert.

Wenn Fragen, dann fragen!

Vorsicht Liferay

Seit Kurzem steht die neue Version für das OpenSource Liferay (5.2.1) zum Download zur Verfügung. Die positive Seite, die World-of-Liferay-Portlets (Sichwort: Social Media) sind per Default integriert. Allerdings muss man hier auch im Code Hand anlegen, damit diese dann auch final und überall funktionieren.

Einige, größere Datenbankprobleme (in 5.1) sind ebenfalls behoben.

Das Schlechte: Die automatische Migration von 5.1. zu 5.2 hat natürlich nicht funktioniert, die eigenen Designs und Templates müssen angepasst werden und, last but not least, Liferay 5.2.1 „schafft“ es, sowohl den Firefox als auch den Safari zum Abstürz/Einfrieren zu bringen.

Allerdings beobachte ich dieses Verhalten nur, wenn das im Standard verteile Chat-Porlet aktiv ist (bis jetzt).

In Summe eher eine bescheidene Vorstellung m.E., zummal es laut Releasenummer ja nur ein Minor-Release sein sollte/müsste.

Die bisher erkannten Probleme „fühlen“ sich eher wie bei einem Major-Release an…

Soziale Netzwerke – Quo Vadis?

Es entstehen immer weitere und neue Soziale Netzwerke, vorallem, weil es auch mit entsprechenden Baukästen immer einfacher wird, diese aufzusetzen.

Allerdings stellt sich bei der entsprechend zu beobachtenden Inflation dieser Plattformen doch auch die Frage, was davon wird wirklich die Jahre überdauern?

Wird das Prinzip des Social Networking überleben und/oder werden auch einige dieser konkreten Plattformen mit uns zusammen alt?
Zumal es ja nicht nur einen Typus „Soziales Netzwerk“ gibt, sondern verschiedene Schwerpunkte mit unterschiedlichen Implementierungen gesetzt werden.

Da gibt es z.B. das Netzwerk für eine bestimmte Altersklasse, das SchuelerVZ, das Netzwerk für eine bestimmte Ausbildungsform, das StudiVZ, das Netzwerk für eine bestimmte Berufsgruppe, Xing, das Netzwerk für die leichte Freizeitunterhaltung, wer-kennt-wen, das Netzwerk für ein spezielles Thema, MobileMonday und so weiter und so fort.

Welche dieser, hier nur auszugweise aufgezählten Einrichtungen werden wir in 5 Jahren noch unter http:// antreffen?

Meine Meinung:

Das Prinzip Social Networking wird auf jeden Fall überleben, als konkrete Ausprägung und als grundsätzliches Anwendungsmuster des modernen Web.

Bei allem anderen bin ich mir unsicher, am ehesten glaube ich daran, dass spezialisierte Netzwerke überdauern werden/können. Bei den allgemeinen glaube ich eher an einen/den typischen Modetrend – „Öfter mal was Neues“.

So wie man immer wieder eine neue Kneipe, eine neue Disco, ein neues Restaurant ausprobieren möchte, und seine Wahl dann zu einem zeitlich begrenzten Favoriten wird, so wird es auch den Netzwerken ergehen. Jede Generation will ihr eigenes, neues Soziales Netzwerk haben, und das immer wieder und regelmässig.

Die Spezialisten-Netzwerke werden aber überdauern, solange dieses Spezialistenthema auch im Markt nachgefragt ist/wird.

Wie ist Eure Meinung?

Das eigene Enterprise Soziale Netzwerk

Gemäß meiner vereinfachten und eigenen Theorie 🙂 gehört zu einem gewissen Reifegrad einer Social Media-orientierten Kundenbindung ein eigenes Soziales Netzwerk (und auch die Bedienung bekannter, öffentlicher Netzwerke wie Facebook, MySpace, Xing etc.).

androidpit

Für das eigene Soziale Netzwerk existieren fertige und gehostete Lösungen, die sofort einsatzfähig (und gut) sind und die meisten notwendigen Features schon mit sich bringen (siehe hier z.B. Ning).

Weiterlesen

Traue keinem Sozialen Netzwerk, welches Du nicht selber entwickelt hast

Klingt jetzt populistischer, als eigentlich erfahren, aber:

2006 haben wir die MobileMonday-Webseite mit einer älteren Version von Liferay gestartet. War nicht besonders schick, aber wir hatten die volle Kontrolle über diese Plattform, so dass wir auch ein 2D-Code-Ticketing-System ohne Probleme integrieren konnten (PicTicket).

Weiterlesen