Qgoda war ursprünglich stark von Jekyll beeinflusst, hat sich aber mittlerweile in sehr vielen Punkten von Jekyll wegentwickelt.
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.
Jekyll can structure a site with tags and categories. Qgoda has arbitrary taxonomies and you decide about their semantics and usage.
Qgoda kann Auflistungen mit beliebigen Filtern erzeugen, nicht nur für Kategorien. Beispiel:
[% posts = q.list(lingua = asset.lingua
type = 'post'
'tags', ['contains', 'Development']
) %]
See Listen und Links for more information!
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:
See [% q.lanchor(name='listings') %] for more information!
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.
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.
Jekyll kommt mit einem integriertem Sass-Compiler, der auf der Ruby-Implementierung von Sass beruht.
But modern web development is a lot more than pre-processing CSS. First of all, chances are that you also want to use JavaScript, do you? And maybe you don't want to use Sass but Less or you even opt for PostCSS only.
All these assets should be syntax-checked, minified, optimized and bundled and, again, the Node.js eco system has the best tools for the job, first Grunt, then Gulp, today Webpack, Parcel, Vite, Rollup, and there are probably more.
Qgoda allows you to configure an arbitrary number of helper processes while watching your site for changes. You typically have one of the build tools like webpack running in watch mode as one helper, and a development web server as a second. And you have the choice. You decide whether you want gulp or webpack, yarn or npm, or just plain Makefiles.
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.
All you have to do is to store the language (resp. language code) of a particular document or asset in a standard variable. If you follow the convention and use lingua, you can save some typing, but you can store the language in any variable you want, and filter by that variable. That's all.
Under normal circumstances, not only regular content differs between languages. You also want to translate certain strings in your template. The quick and dirty way is to store translations in your configuration file _qgoda.yaml:
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.
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.
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.
Qgoda verwendet das Template Toolkit als primäres Template-System, Jekyll verwendet Liquid.
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 %]).
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.
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.
The default name of the qgoda configuration file is _qgoda.yaml, not _config.yml as for Jekyll. That can make a possible migration from Jekyll to Qgoda a little bit easier.
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