- Allgemein
-
Ideen
Zentrale Stelle zum Deployment
Aktuell müssen erstellte Dateien zur Verwendung in Imperia (Templates, Flex-Module, Includes, Workflows, Metafiles, Workflow-Plugins, eigene Controller, Views usw.) in relativ viele verschiedene Verzeichnisse eingespielt werden. Dies mag bei kleineren Projekten noch praktikabel sein. Spätestens wenn die Anforderung besteht, dass mehrere Großprojekte auf einem System parallel laufen sollen, kann dies schnell in größerem Verwaltungsaufwand ausarten. Insbesondere muss man darauf achten, von vorne herein ein skalierbares Schema der Zuordnung einzelner Inhalte einzusetzen, z.B. über Dateinamen, was allerdings schon bei gemeinsam genutzten Komponenten schwierig werden kann.
Ich würde daher folgende Anpassung vorschlagen: Es soll innerhalb eines neuen Verzeichnises (z.B. SITE-DIR/user_projects) die Möglichkeit bestehen, dort innerhalb eigener Namespaces (sprich Unterverzeichnisse) die zu einem Projekt gehörenden Dateien einzuspielen. Das Projekt kann dann vom Superuser über eine Oberfläche aktiviert oder deaktiviert werden. Weiterhin sollte auch die Möglichkeit bestehen, dort hinterlegte nötige Rubriken-Strukturen aus XML-Daten zu importieren.
Customer support service by UserEcho
Die Idee erscheint mir super. Wie man hierbei jedoch ohne ein ausgewachsenes PaketManagement (für gemeinsam genutzte Komponennten) zurecht kommt, ist mir nicht klar. Letzteres (ein PaketManagement was auch abhängigkeiten auflöst usw. ) erscheint mir sehr Aufwändig.
Dieser Punkt wäre aus unserer Sicht auch nur die Kür. Für den Anfang könnte ich mir z.B. ein internes Dummy-User-Projekt mit Komponenten zur gemeinsamen Nutzung vorstellen, die dann in die einzelnen Projekte verlinkt werden. Jedes Projekt könnte eine XML mit Inhalt und Konfigurations-Daten besitzen und wenn beim Einlesen eine Referenz auf das Bibliotheks-Projekt gefunden wird, wird ein symbolischer Link für diese Datei im zu aktivierenden Projekt angelegt. Wenn man die gemeinsame Komponente vorher nicht installiert hat, gibt es bei Aktivierung des Projekts einfach eine Fehlermeldung. Ein komplexes Paket-Management wäre natürlich die Ideal-Lösung, aber zumindest für unsere Zwecke nicht zwingend nötig.
Ich halte das auch für eine sehr gute Idee. Damit wäre es auch um ein vielfaches einfacher Docker Images bereitzustellen.
Wir lösen das anders.
1) als Imperia-Backend nehmen wir dasselbe,
es wird nur per Skript eine andere Rubriken-Grundstruktur importiert, ansonsten achten wir drauf, dass Templates und Flexe über all gleich sind.
2) Live-Modus der Templates ist nur ein Codeinclude, dass den Datensatz als json ablegt.
3) Preview / Frontend sind per Variable (wir pflegen auch die "php"-Variable via system.conf-Variable)
unterscheidbar
und werden vom php-Frontend ausgeliefert.
Routing.php Skript bekommt den Pfad (dir/file) und kann es sich aus einer Elasticsearch holen, oder von der Platte als json und dann für das "gewünschte" Frontend per php-view-templates ausliefern.
Der Vorteil das Template nicht bereits beim Erstellen voll durchgenerieren zu lassen ist, dass man auch später noch mal Bildformate oder Layout ändern kann, ohne dass man alle 300000 Dokumente reparsen müsste (was bei Imperia nicht nur einige Stunden dauert).
Die o.g. Idee finde ich auch super! Gerade im Bereich site/metafiles, site/includes und site/templates ist es doch sehr unübersichtlich.
Wir haben zwar alle unsere Webprojekte komplett in Eclipse verwaltet, wo wir auch mittels Grunt die Dateien direkt auf dem Imperia-Server veröffentlichen, aber eine saubere Projektstruktur auf dem Imperia-Server würde das deployen erheblich vereinfachen.
Somit bräuchten wir in Zukunft die Dateien nur noch das Projektverzeichnis deployen und nicht in x Verzeichnisse.