Questions & Answers

[annick_querfeld]

Guten Morgen,

ich bin Frontend-Entwickler eines Großunternehmen und für einen Kunden sollen wir in zeitnaher Zukunft ein Projekt mit FirstSpirit umsetzen.

Um uns darauf vorzubereiten sitzen wir gerade in der Basisschulung. Das ist auch sehr interessant und wir lernen viele Dinge, aber was für mich als Frontendler der da später drauf entwickeln soll wirklich interessant ist sind zum Beispiel die Fragen, wie in FirstSpirit mit dem Thema Javascript und CSS umgegangen wird.

In der Basis Schulung wird nicht darauf eingegangen. Scheinbar, wenn man etwas über die Advanced Schulung liest, dort aber auch nicht. Genauso wenig findet man auch nur einen Satz dazu in der FirstSpirit Dokumentation (zumindest konnte ich nichts finden, vielleicht stelle ich mich ja aber auch doof an) und im Grunde nichts brauchbares in der Community. Nur andere Leute wie ich, die sich die gleichen Fragen stellen aber nicht wirklich Antworten darauf bekommen haben. Da FirstSpirit ein so geschlossenes System ist, finden man auch im guten alten World Wide Web keine Informationen dazu.

Daher muss ich hier fragen und ich hoffe ich bekomme eine brauchbarere Antwort als in den Threads zuvor.

Dem ersten Eindruck nach ist FirstSpirit echt mächtig und cool und ich sehe interessiert dem kommenden Projekt entgegen und habe Bock loszulegen, dem ersten Eindruck nach muss ich aber auch sagen dass mir der Eindruck entseht dass das Thema Frontend-Entwicklung bzgl CSS und Javascript sehr wenig durchdacht ist bzw. nicht den modernen Ansprüchen entspricht.

Heutztage ist es ja üblich, dass man sowohl in CSS als auch in Javascript in vielen einzelnen Dateien modulbasiert programmiert und am Ende alles CSS zu einem zusammengefügt und minified wird, genauso wie auch beim Javascript und man in der HTML Seite dann nurnoch eine Datei referenziert. Grade hier, in einem CMS wo es modulbasiert und templatebasiert zur Sache geht macht dies ja erst recht Sinn. Desweiteren ist es geläufig heutzutage preprocessoren für CSS zu benutzen, etwa wie SASS oder LESS. Da sie einem die Arbeit enorm vereinfachen und den Code viel besser und sauberer strukurieren lassen. Etwas, auf das glaube ich heutzutage kein Frontend-Entwickler verzichten möchte. Ebenso die Integration von js hint and css lint. Oder automatisiertem Frontend Testing, zum Beispiel das Testen von Javascript bspl über Jasmine oder ähnliches. Oft wird das alles in Kombination mit Grunt zum Beispiel genutzt.

Als Entwickler stelle ich mir natürlich die Frage, kann ich diese Dinge in Zusammenhang mit FirstSpirit nutzen, oder geht es nicht, und wenn ja, gibt es Beispiele dazu wie man entsprechendes in FirstSpirit integrieren kann, auch so, dass die Vorschauen weiter funktionieren? Leute die es bereits erfolgreich umgesetzt haben? Irgendwelche Anhaltspunkte?

Aktuellen Eindruck nach wirkt es so dass das Konzept einfach das ist im media store Javascript und CSS Dateien liegen zu haben und sie alle einzeln einzubinden. Was mir Bauchschmerzen bereitet was zum Beispiel Dinge wie Performance  angeht.

Ich hoffe es gibt jemanden der meine Bedenken beruhigen kann. Vielleicht fehlen mir auch einfach nur die richtigen Informationen oder ich schaue an den falschen Stellen. Ich habe es leider nicht geschafft zu dem Thema etwas brauchbares zu finden.

Viele Güße, Annick

[udorudi]

Guten Morgen,

sollte die eigentliche HTML/CSS-Entwicklung nicht außerhalb von Firstspirit liegen und eher dort mit entsprechenden Frameworks & Tools erfolgen ? Dann wären nach sporadischen Modifikationen nur einmalig 1-2 generierte CSS/JS-Files aus dem Klickdummy zu ersetzen.

Oder finden nach GoingLive immer noch täglich dutzende CSS-Updates statt, und die Frontendentwicklung soll mehr oder weniger vollständig in FS integriert werden? Dann müsste man entsprechende Scripte / Module entwerfen, die die gewünschten Endformate eigenständig produzieren.

Viele Grüße

[philippr]

Hallo Annick,

unser Workflow sieht an der Stelle genau so aus wie von Udo beschrieben:

In einem Klickmodell (außerhalb des CMS) liegen CSS und JS Modular vor, dann übernimmt ein Grunt Build für uns folgende Aufgaben:

- HTML Module (*.hbs Dateien generiern und zu HTML Dateien zusammen setzen) = Klickmodell (Wir nutzen an der Stelle Handlebars, um das HTML bereits Modular aufzusetzen, so wird z.B. das HTML der Navigation nur an einer Stelle gepflegt und in alle weiteren Seiten inkludiert, wenn man das ganz sauber aufsetzt, entsprechen die HTML Module später in etwa den Vorlagen in FirstSpirit)

- CSS und JS (zusammen setzen, ggf. minifizieren je nach dem ob für DEV oder PROD)

- Bilder innerhalb von CSS (xxx:url(xyz.png)) werden durch ein $CMS_REF()$ ersetzt wobei der Dateiname ohne Endung dem Referenznamen des Medienobjektes in FS entspricht. So könnendie Bilder ebenfalls in FirstSpirit abgelegt werden und die URL wird automatisch von FirstSpirit erzeugt. (Dazu muss an dem CSS-Medium in FirstSpirit "Datei parsen" aktiviert werden, dann werden die CMS-Ausdrücke wie z.B. $CMS_VALUE()$ interpretiert)

- Die Dateien können dann mit der Funktion externen Synchronisierung "automatisch" ins CMS importiert werden.

Der Workflow für Änderungen und Anpassungen an der Webseite gehen bei uns dann immer über das Klickmodell. Dann werden die Anpassungen auf unserem DEV System ins CMS gespielt. Alle Angepassten FirstSpirit Objekte werden anschließend über ein Feature-Transport an ein Konsolidierungssystem bzw. das Produktivsystem übertragen.

Viele Grüße,

Philipp

[davidamend]

Gleiches Anliegen, anderer Post :

https://community.e-spirit.com/message/24378#24378

https://community.e-spirit.com/message/24379#24379

@Philipp: Seid ihr zufrieden mit der Lösung?

Sehe ich auch als ein bevorzugtes Modell.

Wie löst ihr die Integration von serverseitigen Code Applets?

Ist soewas überhaupt mit FirstSpirit sinnvoll, oder ist es von der Architektur eher für AJAX Content dynamische Generierung im Browser ausgelegt?

Resultat: FirstSpirit als CMS ist dann weniger/kein ein Content Management System , sondern der Grunt Build. FirstSpirit agiert dann nur noch als Content-Erzeuger.

- sehr ihr das genauso?

Viele Grüße,

David

[philippr]

Hallo David,

die Lösung funktioniert und hat sich als praktikabel erwiesen:

• auch FirstSpirit unbedarfte können an dem Klickmodell arbeiten ohne sich einloggen zu müssen
• Jeder Frontend Entwickler arbeitet weiterhin mit dem Editor seiner Wahl und für das Testen des HTMLs muss keine FirstSpirit Generierung stattfinden

Serverseite Applikationsbestandteile, hier gibt es viele Antworten mal ein paar der bereits von uns umgesetzten Lösungswege:

• FirstSpirit generiert JSP Seiten die dann beim Aufruf serverseitg verarbeitet werden.
• FS Integration (ein FS-Modul) damit kann man via TagLib eine JSP bauen die beim Aufruf der Seite direkt auf eine FS Datenquelle zugreift.
• FirstSpirit deployed HTML und alle dynamischen Inhalte werden via AJAX und einem Webservice/REST nachgeladen
• Aus einer Datenquelle wird mit Hilfe der FirstSpirit Content-Projektion aus jedem Datensatz eine HTML Seite generiert. Mit FS Boardmitteln kann dann ein Paging, oder ähnliches ergänzt werden.
• Aus FirstSpirit wird neben den HTML Seiten auch ein JSON Format erzeugt (eigene Seitenvorlage mit Dateiendung .json). Dieses enthält Meta-Informationen zu den geparsten HTML Seiten (wenn diese z.B. aus einer Datenquelle kommen "Content-Projektion"). Via JS kann das JSON eingelesen werden um z.B. dynamische Filter zu erzeugen (z.B. via Angular.js). Skaliert natürlich nur bedingt gut
• Eine Applikation läuf komplett unabhängig von FirstSpirit und baut über die API eine Verbindung zu dem FS Server auf, um dann bestimmte Inhalte aus FS zu holen.
• Während der Generierung wird eine externe "Datenquelle" befüllt um dann auf der Webseite auf dieser Datenquelle dynamische Abfragen auszulesen.

-> Eine Entscheidung für eine entsprechende Variante hängt total von den Anforderungen des entsprechenden Anwendungsfalls  ab.

Dein Resultat habe ich nicht so recht verstanden...

FirstSpirit ist eben ausschließlich ein Web Content Management System. ("Best-of-Breed" - Ansatz)

• Der Grunt-Prozess erzeugt lediglich das Klickmodell.
• FirstSpirit erzeugt die Webseite, die später vom User betrachtet wird.

Ich hoffe das hilft dir weiter :smileyconfused:

Viele Grüße,

Philipp

[davidamend]

Hallo Philipp,

vielen Dank nochmal für die ausführlich Antwort.

Auch wenn ich mir mit meiner Zeit gelassen habe: wir haben viel darüber die letzten Wochen diskutiert.

Wie meinst Du: Grunt erzeugt das Klick Modell:

Klick-Modell == First Spirit Oberfläche?

-> Ihr habt alle files außerhalb von FirstSpirit. FirstSpirit Templating Code schreibt ihr vom Grunt Prozess dann in das CMS System?

Gefällt mir sehr gut, FirstSpirit als Content only zu verwenden, also als Datenquellen.

Wenn ihr JSPs verwendet, wird dann zwangsweise das CMS Kompilat komplett auf einen ApplicationServer deployt. Vermutlich habt ihr dann auch einen Serverstate und Monolithisches System.

(Gleiches bei uns).

Mit Resultat meinte ich eben: Das CMS als Datenquelle verwenden, um JSON bzw. HTML Schnipsel in die Anwendung zu laden. - nicht umgekehrt: FirstSpirit ist das führende System und lädt Anwendungen von extern.

[annick_querfeld]

Hallo Zusammen,

entschuldigt bitte meine viel zu späte Antwort. Ich wurde auf ein anderes Projekt abgezogen und war dann erstmal komplett raus aus dem Thema. Nun aber werde ich doch auf dem Projekt arbeiten.

Also wenn ich euch jetzt richtig verstanden habe, baut ihr ausgelagert als grunt project unter Nutzung von Handlebars, Sass/Less und co einen Klickdummy. Die generierten Files (css und javascript) ladet ihr mit der Content Synchronisation in First Spirit und die Handlebar files nutzt Ihr dann als Vorlage für die Module in FirstSpirit und übertragt den Teil händisch?? Kann man das so kurz zusammengefasst sagen?

Vielen Dank für die vielen ausführlichen Antworten.

Viele Güße, Annick

[CVogel]

Hallo zusammen,

mit Version 5.2 von FirstSpirit gibt es den Template-Wizard. Damit lassen sich bequem über eine GUI HTML-Clickdummies analysieren, Templates ausschneiden und sämtliche referenzierten Medien importieren.

Der von uns empfohlene Weg ist daher

* HTML, JS und CSS ausserhalb von FirstSpirit mit den gewohnten Tools entwickeln

* über gewohnte Build-Tools den Clickdummy erzeugen

* mit Hilfe des Template-Wizards den Clickdummy importieren und die Templates zuschneiden

* wenn nötig, manuelle Anpassungen an den Templates durchführen

Die zweite Frage (wie geht man mit dynamischen Content um) ist total projektspezifisch. Philipp hat die Möglichkeiten ziemlich gut zusammengefasst. Hinzufügen möchte ich eigentlich nur, dass wir für

Während der Generierung wird eine externe "Datenquelle" befüllt um dann auf der Webseite auf dieser Datenquelle dynamische Abfragen auszulesen.

das Modul UX-Bridge im Angebot haben.

Viele Grüße

Christian