Architekturentscheidung: Anwendungen im CMS oder CMS aus Anwendungen
Author: davidamend
Publication Date: 4/27/2015 7:27
Guten Tag,
bezüglich den hier erklärten Problemen, https://community.e-spirit.com/thread/4535?tstart=0
die uns nicht nur massiv Performance kosten,
sondern auch zu unkontrolliertem Dependency Management führen.
stellt sich die Frage nach einem klaren Vorgehen. Außerdem wäre eine möglichst loose Kopplung zwischen CMS und
JS/CSS sowie Serverseitigen Appcode super! Ein möglicher Grund ist die Einbindung von Inhalten über First Spirit
UND einem anderen CMS System, also "Sharen" von Inhalten über Grenzen hinweg.
Hierbei würde mich interessieren, welche Variante zu empfehlen ist und aus welchen Gründen:
1. Das von FirstSpirit gebaute Release, bestehend aus statische Resourcen, insbesondere HTML,
wird auf den Application Server kopiert, wo dann JSF, PHP ausführbar ist und dynamischer Anwendungscode deployt ist.
Im FirstSpirit HTML steht dann der "include" bzw. "import" zu den jeweiligen dynamischen Anwendungsteilen.
2. Der Anwendungs bzw. Appserver ist das zentrale System. Statische CMS Inhalte werden vom Appcode abgerufen durch bspw. AJAX Calls oder Serverseitigen HTTP-Client Aufrufen und an geeignete Stelle gepackt ( bspw. dynamisch in ein Modal, oder einer Seite).
Worauf ist besonders bei der empfohlenen Lösung zu achten. Wie kann das konkret aussehen?
-
Author: marza - 5/12/2015 16:21
Hallo David,
sowohl 1 und 2 sind bereits erprobt.
Zu 1)
Natürlich kann man statt reinem HTML-Code auch XML, JSON, PHP-, JSF oder JSP-Code von FirstSpirit erzeugen lassen. Dieser wird dann entsprechend deployt und dann im Falle von PHP, JSF oder JSP von einem Live-System wie einem Apache HTTP Server mit PHP oder einem Apache Tomcat ausgeführt. Bei XML und JSON sollte das Fremdsystem eine entsprechende Schnittstelle bereits bieten (oder diese muss selbst entwickelt werden).
Zu 2)
a) Es gibt etliche kostenpflichtige Integrationen mit z.B. LifeRay, IBM WebSphere Portal, etc. siehe hierzu http://www.e-spirit.com/marketplace/overview, Stichwort "Portal Integration".
b) Oder der Einsatz einer kostenspflichtigen Produkterweiterung wie der UX-Bridge (http://www.e-spirit.com/marketplace/de/ux-bridge) die eine JMS-1.1-Anbindung bereitstellt.
Ohne weitere konkrete Informationen von Deiner Seite zu haben: Es kommt also immer darauf an, welches System das Ziel ist und was man haben möchte bzw. bereit ist einzusetzen (Zeit/Geld/Personal).
Grüße Marian
0 -
Author: MichaelaReydt - 5/19/2015 10:20
Hallo David,
benötigst du noch weitere Hilfe oder konnte Marian deine Frage bereits beantworten?
In diesem Fall wäre es super, wenn du seine "richtige Antwort" markierst.
Viele Grüße
Michaela
0 -
Author: davidamend - 5/21/2015 8:25
Hallo Marian,
danke für die Antwort.
Auf der Grünen Wiese: Welche Variante wird bevorzugt? Womit machen Kunden bessere Erfahrungen?
Oder lässt Ihr diese Entscheidung bewusst die Unternehmen selbst treffen?
zu deiner Antwort 2.) -> Ein Portal Integrationsserver ist nicht unbedingt notwendig.Aber vielen Dank für die Tipps. Reicht da nicht auch ein einfacher AJAX Aufruf(oder Synchroner Serverseitiges laden), um von FirstSpirit erzeugten HTML/JSON/XML Snippets in die Anwendung zu laden?
-> Ist die Empfehlung hier für eine Mischlösung, oder 1.), 2) ?
0 -
Author: marza - 5/22/2015 15:20
Hallo David,
eine der großen Stärken von FirstSpirit ist die Fähigkeit sich in viele Umgebungen zu integrieren. Wir machen bewusst keine Vorgaben, wie das Produktionssystem auszusehen hat.
Die Frage vielmehr ist, wie dynamisch muss die Web-Seite sein? Reichen einfache (statische) HTML-Seiten (die aus FirstSpirit beliebig oft aktualisiert werden können) oder muss die Web-Seite auf Benzutereingaben reagieren (z.B. wie ein Web-Shop oder eine Suchmaschine).
Letztendlich gibt der Kunde die Zielplattform vor. Welche Systeme sind vorhanden und müssen diese weiterwendet werden?
Grüße Marian
0 -
Author: thmarx - 6/15/2015 12:21
Hallo David,
benötigst Du noch weitere Hilfe oder hat Dir die Antwort von Marian geholfen?
Viele Grüße
Thorsten
0
Please sign in to leave a comment.
Comments
5 comments