Unterschiede zu Jekyll

Diese Seite erklärt, in welchen Punkten sich Qgoda von Jekyll unterscheidet, und weshalb dem so ist.

Qgoda war ursprünglich stark von Jekyll beeinflusst, hat sich aber mittlerweile in sehr vielen Punkten von Jekyll wegentwickelt.

Allgemeine Unterschiede

Qgodas Philosophie unterscheidet sich deutlich von Jekyll. Die Pflege einfacher Web-Sites solllte mit Qgoda mindestens so einfach wie mit Jekyll sein, aber gleichzeitig auch komplexere Anforderungen erfüllen, wenn möglich ohne Erweiterungen.

Taxonomien

Jekyll kann Web-Sites über Tags und Kategorien strukturieren. Qgoda verwendet beliebige und beliebig viele Taxonomien, mit frei bestimmbarer Semantik und Verwendung.

Auflistungen

Qgoda kann Auflistungen mit beliebigen Filtern erzeugen, nicht nur für Kategorien. Beispiel:

[% posts = q.list(lingua = asset.lingua
                  type = 'post'
                  'tags', ['contains', 'Development']
                 ) %]

Siehe Listen und Links for weiterführende Informationen!

Links und Querverweise

Diese funktionieren prinzipiell wie Auflistungen. Allerdings wird der Filter so definiert, dass nur ein Treffer statt einer Liste produziert wird. Der letzte Satz des vorangehenden Absatzes sieht im Quelltext beispielsweise so aus:

Siehe [% q.lanchor(name='listings') %] für weiterführende Informationen!

Die Funktion q.lanchor() erzeugt einen Link zum Dokument mit dem Namen (name) „listings“, ganz gleich, wo dieses Dokument liegt. Links in Jekyll haben dagegen immer hartkodierte Ziele. Die Verwendung der Funktion hat den Vorteil, dass verweisende Dokumente nicht angefasst werden müssen, wenn sich das Zieldokument ändert.

Kein Web-Server im Lieferumfang

Qgoda hat keinen eingebauten Web-Server. Weshalb? Faule Entwickler?

Das auch, denn faule Entwickler sind gute Entwickler.

Qgoda ist ein Tool, mit dem statische Web-Sites generiert werden, und es folgt dabei dem Unix-Konzept von DOTADIW, oder „Do One Thing and To it Well“, auf Deutsch ungefähr „erledige nur eine Aufgabe, aber dafür richtig“. Web-Entwicklung findet heute vornehmlich im Ökosystem von Node.js statt, und dieses Ökosystem hat keinen Mangel an guten Entwicklungs-Web-Servern wie http-server, Browsersync oder webpack-dev-server, um nur einige zu nennen.

Und ehrlich gesagt, sehen die aktuell in Perl, Python oder Ruby geschriebenen Web-Server ziemlich lahm neben ihren Geschwistern bei Node.js aus.

Sass? Helper-Applikationen!

Jekyll kommt mit einem integriertem Sass-Compiler, der auf der Ruby-Implementierung von Sass beruht.

Aber moderne Web-Entwicklung bedeutet mehr, als CSS durch einen Präprozessor zu jagen. Zunächst einmal ist es nicht ganz unwahrscheinlich, dass auch JavaScript zum Einsatz kommt, oder? Und eventuell willst du nicht Sass sondern Less einsetzen, oder direkt auf PostCSS alleine setzen.

Und all diese Assets sollten syntax-geprüft, minifiziert, optimiert und gebündelt werden, und wieder hat das Node.js-Ökosystem traditionell die besten Tools für den Jobb am Start, erst Grunt, dann Gulp, im Moment Webpack, und wer weiß, welcher neue Stern in drei Wochen am Firmament erscheint?

Mit Qgoda lassen sich beliebig viele Hilfs-Applikationen als Helper konfigurieren, die im Hintergrund mitlaufen, während die Site auf Änderungen überwacht wird. Typischerweise ist das eines der Build-Tools wie webpack, das im Watch-Modus läuft. Und parallel wird ein Entwicklungs-Web-Server als zweites Tool gestartet. Du entscheidest selbst, ob du Gulp oder Webpack, Yarn oder NPM oder ganz konventionell Makefiles einsetzt.

Mehrsprachige Sites

Jekyll hat keine integrierte Unterstützung für Mehrsprachigkeit. Qgoda hat ebenfalls keine explizite Unterstützung für mehrsprachige Web-sites; es funktioniert einfach nur von alleine.

Alles, was zu tun ist, ist die Sprache (bzw. den Sprach-Code) eines Dokumentes oder Assets in einer Standard-Variablen zu speichern. Wenn man der Konvention folgt und lingua als Variable verwendet, spart man etwas Tipperei, aber man kann die Sprache in jeder beliebigen Variablen speichern, und dann nach dieser Variablen filtern. Mehr ist es nicht.

Unter normalen Umständen gibt es nicht nur beim regulären Content Unterschiede zwischen den Sprachversionen. Auch Strings aus den Templates müssen übersetzt werden. Der typische von anderen Programmen verwendete Hack besteht darin, Übersetzungen in der Konfigurationsdatei _config.yaml zu speichern:

translations:
  en:
    privacy: Data Privacy
    go_to_top: To top of the page
  de:
    privacy: Datenschutz
    go_to_top: Zum Seitenanfang
  bg:
    privacy: Конфиденция
    go_to_top: На горе

Im Template schreibt man dann:

[% l = asset.lingua %]

<a href="./privacy/">[% config.translations.$l.privacy %]</a>
|
<a href="#top">[% config.translations.$l.go_to_top %]</a>

Das mag für eine Handvoll Strings gerade noch akzeptabel sein, wird aber schnell zu einem Wartungsalbtraum für größere Sites. Besser ist es, die Strings einfach in der Grundsprache zu schreiben und lediglich zu markieren:

[% USE gtx = Gettext('your-site-id', asset.lingua) %]

<a href="./private/">[% gtx.gettext('Privacy Policy') %]</a>
|
<a href="#top">[% Go to top %]</a>

Diese Strings können dann zur Übersetzung in .po-Dateien extrahiert werden, und die fertigen Übersetzungen werden kompiliert und in der Site installiert. Das folgt exakt dem Standard-Workflow für GNU Gettext, dem De-facto-Standard für Lokalisierung von Open-Source-Software.

Standardmäßig ignorierte Dateien

In Qgoda, a file _logs/access.log is ignored, in Jekyll it would be processed. The default ignore rule in Qgoda is ignore all top-level files and directories the names of which start with an underscore. Rationale: Qgoda's default makes a whole lot of sense.

Rebuild Triggers

Qgoda will accumulate all rebuild triggers during a rebuild. All changes made while Qgoda is rebuilding a site will result in a single rebuild attempt after the changes. Jekyll will remember, whenever a modification is recorded after the grace period, and create a snapshot, whenever you hit CTRL-S. This is almost never what you want or need. Contrary to Jekyll, Qgoda will also honor CTRL-C while it is busy ignoring your wishes.

Template-System

Qgoda verwendet das Template Toolkit als primäres Template-System, Jekyll verwendet Liquid.

Syntax

Liquid verwendet doppelte geschweifte Klammern für Objekte ({{ variable }}) und geschweifte Klammern mit Prozentzeichen für Tags ({% if logged_in %}).

Template Toolkit verwendet nur [% ... %]. Direktiven (den Tags von Liquid vergleichbar) benutzen nur Großbuchstaben ([% IF logged_in %]).

Datentypen

Liquid unterstützt nur eine maximale Verschachtelung von einer Ebene bei der Dereferenzierung von Variablen. Konstrukte wie {{ user.address.street }} sind nicht möglich. Variablenzugriffe beim Template Toolkit können beliebig tief verschachtelt werden und auch Methoden von Perlobjekten aufrufen.

Code in Templates

Da Variablen für Template Toolkit auch Perl-Objekte enthalten können, ist es auch möglich, Methoden dieser Objekte aufzurufen. Qgoda macht davon intensive Gebfrauch, und viele Dinge, die mit Jekyll nicht möglich sind, sind genau aus diesem Grunde in Qgdoa trivial umzusetzen.

Konfiguration

Der vorgegebene Name für die Konfigurationsdatei von Qgoda ist _config.yaml, nicht _config.yml wie bei Jekyll. Das macht eine mögliche Migration von Jekyll zu Qgoda geringfügig einfacher.

Default-Werte

Vorgabewerte (Defaults) in Qgoda werden über flache Listen von Suchmustern und nicht über verschachtelte Datenstrukturen wie in Jekyll konfiguriert. Beispiel:

defaults:
  - files: /posts
    values:
      type: post
  - files: /posts/en
    values:
      lingua: en
  - files: /posts/de
    values:
      lingua: de
  - files: /images/**/*.png
    values:
      view: raw