Ich versuche, etwas "Portlet-Server" -ish auf der Google App-Engine zu bauen. (als Open Source)Portlet Container wie Pluto oder Jetspeed auf Google App Engine?
Ich würde gerne die JSR168/286-Standards verwenden, aber ich denke, dass die Einschränkungen der der App-Engine es irgendwo zwischen schwierig und unmöglich machen wird.
Hat jemand versucht, Jetspeed oder eine Anwendung zu starten, die pluto intern auf der Google App-Engine verwendet?
Aufgrund meines derzeitigen Kenntnisstand von Portlets und dem Google App Engine Ich bin antizipieren diese Probleme:
Eine WAR-Datei mit Portlets aus dem Einsatz Standpunkt ist mehr oder weniger ein kompletter Webapp (ja, ich weiß, dass es nicht wirklich funktioniert ohne ein Portal Server). Die WAR-Datei kann eine eigene web.xml etc. enthalten. Das macht die Bereitstellung in der App-Engine ziemlich schwierig, weil die Apps nicht für einander sichtbar sind, so dass alle Portlet-enthaltenden Archive in der WAR-Datei enthalten müssen implementierter "app-Engine-basierter Portalserver".
Die „Portlets“ sind (zumindest in liferay) beginnt als permanenter Servlet Prozesse auf der Grundlage ihres portlet.xmls und web.xmls die für jedes Portlet-Archiv an der gleichen Stelle befindet, die geladen wird. Ich denke, dass dies in der App-Engine problematisch sein kann, da alles in einer großen "Web-App" ist, so dass es schwierig sein kann, auf die portlet.xmls von jedem Archiv zuzugreifen .
Dies verhindert meiner Meinung nach eine 100% ige Kompatibilität.
Gibt es jemanden, der Erfahrung mit der Kombination von Portlets und der App-Engine hat?
Denkst du, es ist machbar, Jetspeed, Pluto oder einen anderen Portlet-Container zu ändern, um auf der App-Engine ausführen zu können?
Ich teile Ihre Bedenken hinsichtlich der Probleme mit der Portlet-Spezifikation. Derzeit denke ich darüber nach, meine eigene "Gloudlet" Spezifikation für Module zu definieren, die in meinem Container laufen. Ich werde es ähnlich wie JSR286 gestalten, aber innerhalb der Beschränkungen der App-Engine. BTW: Wenn Leute mir helfen wollen, das Standard/Framework/Tool zu erforschen und zu bauen: http://code.google.com/p/gludy/ ist das Projekt, das ich dafür gestartet habe. –
Ehrlich gesagt bin ich mir nicht sicher, ob das ein sinnvolles Maß an Abstraktion ist. Die Portlet-Spezifikation IMHO stellt eine architektonische Sackgasse dar (ironisch, wenn man bedenkt, wie viel Portal/Portlet ich gearbeitet habe).Ich denke, das clientseitige Compositing ist die Art und Weise, wie die gesamte Spezifikation ausgeführt wird, mit SSO-ähnlichen gemeinsamen Anwendungssitzungen und einer attributbasierten Authentifizierung, die alle anderen interessanten Aspekte dessen, was Portlets tun, ausfüllt. Ich würde ernsthaft über die Einbeziehung von Widgets (entweder standardisiert oder einfach) über den Versuch, eine andere modulare HTML-Snippet-Architektur zu entwickeln. – jayshao
Was meinst du mit "clientseitige Zusammensetzung"? AJAX-basiertes Abrufen von Widgets? Aber woher würdest du die Definition einer "Seite" bekommen? Ich versuche, den Rahmen für den Aufbau kompletter Websites zu schaffen. Ich denke nicht, dass Widgets hier den Trick machen würden. –