Skip to content

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

  1. compile ’*’ do
  2.   if item[:extension] == ‘md’
  3.     filter :kramdown
  4.   end
  5. end

genügt nunmehr mit dem neuen full format ein einfaches

  1. compile ’/**/*.md’ do
  2.   filter :kramdown
  3. 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.)

Trackbacks

Netz - Rettung - Recht am : Nanoc: Upgrade von 3.x auf 4.x

Vorschau anzeigen
Nanoc nutze ich schon mehr als drei Jahre zur Erzeugung verschiedener Websites; aber wie das so ist bei verschiedenen und zudem historisch gewachsenen Installationen, je mehr und je komplexer ein Werkzeug einsetzt, desto größer ist der Angang bei notwendi

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Favatar, Pavatar, Twitter, Identica, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck