Aller au contenu principal

Behandlung von CSS und Javascript in FirstSpirit

Commentaires

7 commentaires

  • Zendesk API User
    Author: udorudi - 4/23/2015 11:34

    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

    0
  • Zendesk API User
    Author: philippr - 4/23/2015 13:01

    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

    0
  • Zendesk API User
    Author: davidamend - 4/27/2015 7:56

    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

    0
  • Zendesk API User
    Author: philippr - 4/27/2015 20:08

    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 :smileywink:
    • 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

    0
  • Zendesk API User
    Author: davidamend - 5/21/2015 8:18

    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.

    0
  • Zendesk API User
    Author: annick_querfeld - 7/21/2015 14:04

    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

    0
  • Zendesk API User
    Author: CVogel - 7/28/2015 7:19

    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

    0

Vous devez vous connecter pour laisser un commentaire.