nanoc 4.0.0 beta 1
Bereits mehrfach hatte ich über nanoc berichtet, dessen Entwicklung nunmehr wieder mit Elan fortschreitet.
Seit einigen Tagen gibt es die erste Beta-Version von nanoc 4.0 mit bereits teilweise angepasster Dokumentation - und obwohl dieses Release eigentlich keine neuen Features enthalten, sondern nur den Code für zukünftige Veränderungen vorbereiten soll, gibt es einige Neuigkeiten zu vermelden:
In den
Rules
können nunmehr erweiterte Platzhalterzeichen (Globs) verwendet werden. Gab es bisher nur die Möglichkeit,*
und+
zu verwenden, bspw. in der Form/projects/*/
, gibt es in nanoc 4.0 neue Möglichkeiten wie*
contra**
oder Zeichensätze wie[abcdefg]
oder auch Auswahllisten wie{foo,bar}
. Vermutlich wird das der neue Default.Von manchem lange erwartet gibt es in der neuen Version zwei verschiedene Formate für Items, also einzelne Quelltextdateien: full format (neu) und stripped format.
Traditionell wurden Quelltext-Dateien in nanoc durch ihren Namen ohne Erweiterung identifiziert, die Datei /projekte/2015/arche.md
im Verzeichnis content
konnte mithin als /projekte/2015/arche/
angesprochen werden. Da nanoc - ohne Änderungen an den Rules
- standardmäßig aus jeder Quelltext-Datei ein Verzeichnis deren Namen und einer index.html
erzeugte, also aus dem Quelltext /projekte/2015/arche.md
die Datei /projekte/2015/arche/index.html
wurde, die als http://example.com/projekte/2015/arche/
aufgerufen werden kann und soll, war das durchaus konsequent. Es verlangte vom Neubenutzer aber einiges an Eingewöhnungsaufwand und hatte vor allem den Nachteil, dass es keine Quell-Dateien geben durfte, die sich nur in der Erweiterung unterscheiden: die Dateien glyphicons-halflings-regular.ttf
und glyphicons-halflings-regular.svg
, um mal ein Beispiel aus der Praxis zu wählen, durfte es nicht nebeneinander im selben Verzeichnis geben.
Nunmehr gibt es stattdessen auch die Möglichkeit, Identifier für Items in ungekürzter Form zu erzeugen. Die Datei /projekte/2015/arche.md
hat für nanoc dann nicht mehr den Identifier /projekte/2015/arche/
, sondern /projekte/2015/arche.md
. Das hat mehrere Vorteile: es ist einfacher zu verstehen, in Rules
können nunmehr ohne Verrenkungen Dateien mit bestimmten Endungen referenziert werden, und es dürfen Dateien mit identischen Namen, aber unterschiedlichen Endungen vorkommen. Bei der Generierung von Zieldateien mit anderer Endung (meistens ja .html
) hilft dann die neue Methode @item.identifier.without_ext
, die für /projekte/2015/arche.md
entsprechend /projekte/2015/arche
zurückliefert, also wie gewohnt, nur ohne abschließenden /
.
Benötigt(e) man mit dem stripped format zur Umwandlung von Markdown-Quelltexten in HTML ein Konstrukt wie
- compile ‘*’ do
- if item[:extension] == ‘md’
- filter :kramdown
- end
- end
genügt nunmehr mit dem neuen full format ein einfaches
- compile ‘/**/*.md’ do
- filter :kramdown
- end
Einen - mehr oder weniger großen - Nachteil hat das full format aber: es kann bei den Items - prinzipbedingt - das Konzept von “Eltern” und “Kindern” nicht mehr geben. Mit dem stripped format war klar, dass das Element /projekte/2015/arche/
ein Kind von /projekte/2015/
ist, und dieses wiederum ein Kind von /projekte/
. Mit dem full format können aber “oberhalb” von /projekte/2015/arche/
die Dateien /projekte/2015.md
und /projekte/2015.css
nebeneinander existieren, so dass die Frage nach dem “Eltern”-Element sich nicht mehr eindeutig beantworten lässt. Es gibt also keine Baumstruktur der Elemente mehr - das kann u.a. die Erzeugung einer Navigation auf die bisher übliche Weise unmöglich machen.
Insgesamt bin ich aber auf nanoc 4.0 und vor allem dann die folgenden Versionen sehr gespannt!
(Für das Upgrade von nanoc 3.x auf nanoc 4.0 gibt es natürlich einen Upgrade Guide.)
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt