Arbeiten mit Daten, Assets und Vorlagen in Middleman

() translation by (you can also view the original English article)

Dieses zweite Tutorial zum Erstellen statischer Websites mit Middleman taucht etwas tiefer in das Framework ein. Am Ende sollten Sie genug wissen, um Ihr eigenes Projekt von Grund auf neu zu erstellen. Wir werden Themen wie Datendateien, hübsche URLs, Projektvorlagen und die Asset-Pipeline behandeln, also legen wir los!

Datei

Nachdem Sie also bereits das erste Tutorial befolgt haben, haben Sie bereits gelernt, mit Daten zu spielen. Titelseiten, die in den dreifach durch Bindestrich getrennten Abschnitten einzelner Seiten gespeichert sind. Sie können auch separate Datendateien in YAML oder JSON schreiben und diese in einem "/data"-Verzeichnis ablegen. Dies ist nützlich, wenn Sie komplexere Websites mit Daten haben, die sich selten ändern, und wenn Sie diese Daten nicht direkt in Ihrem HTML-Code verwalten möchten.

Nehmen wir an, Sie haben das Recht, alle James-Bond-Filme zu verkaufen. Wir könnten eine Liste von ihnen in eine Datendatei einfügen und sie unserer Ansicht nach durchgehen. Wenn wir diese Daten ändern oder aktualisieren müssen, wenn ein neuer Film verfügbar ist, müssen Sie diese Änderung nur in Ihrer .yaml- oder .json-Datendatei anwenden. Ich würde dies nicht für Daten empfehlen, die in irgendeiner Weise komplex sind. es ist machbar, fühlt sich aber sehr zweifelhaft und falsch an.

So könnte beispielsweise eine Datei /data/bond.yaml aussehen:

movies:
- title: "Dr. No"
  year:  "1962"
  text:  "John Strangways, the British Intelligence (SIS) Station Chief in Jamaica, is killed. In response, British agent James Bond—also known as 007—is sent to Jamaica to investigate the circumstances. During his investigation Bond meets Quarrel, a Cayman fisherman, who had been working with Strangways around the nearby islands to collect mineral samples. One of the islands was Crab Key, home to the reclusive Dr. No."
  image: "bond_movie_01.png"
- title: "From Russia with Love"
  year:  "1963"
  text:  "SPECTRE's expert planner Kronsteen devises a plot to steal a Lektor cryptographic device from the Soviets and sell it back to them while exacting revenge on Bond for killing their agent Dr. No; ex-SMERSH operative Rosa Klebb is in charge of the mission. She recruits Donald "Red" Grant as an assassin and Tatiana Romanova, a cipher clerk at the Soviet consulate in Istanbul, as the unwitting bait."
  image: "bond_movie_02.png"
- title: "Goldfinger"
  year:  "1964"
  text:  "Bond is ordered to observe bullion dealer Auric Goldfinger: he sees Goldfinger cheating at cards and stops him by distracting his employee, who is subsequently killed by Goldfinger's Korean manservant Oddjob. Bond is then instructed to investigate Goldfinger's gold smuggling and he follows the dealer to Switzerland. Bond is captured when he reconnoitres Goldfinger's plant and is drugged; he is taken to Goldfinger's Kentucky stud farm and is imprisoned. He escapes briefly to witness Goldfinger's meeting with U.S. mafiosi, who have brought the materials he needs for an operation to rob Fort Knox."
  image: "bond_movie_03.png"
...

Dann so in source/bond-movies.html.erb ausgeben:

1	<h2>Bond movies</h2>
2	<ol>
3	<% data.bond.movies.each do \|movie\| %>
4	<li>
5	<%= image_tag movie.image %>
6	<h3><%= movie.title %></h3>
7	<h6><%= movie.year %></h6>
8	<p> <%= movie.text %></p>
9	</li>
10	<% end %>
11	</ol>

Einer der Vorteile dieser Datendateien besteht darin, dass sie sicher sind. Noch besser ist, dass Ihr /data-Verzeichnis mit allen YAML- oder JSON-Daten nicht auf Ihren Live-Server übertragen wird. Während der Build-Phase werden Ihre Daten lokal in Ihre Vorlagen eingefügt, bevor sie bereitgestellt werden. Danach sind die Daten in Ihren Ansichten einfach statisches HTML. Ziemlich cool!

Regeln der Namensgebung

Ein Wort zu Namenskonventionen hier. Wenn Sie Datendateien in einem "data"-Verzeichnis haben, erhalten Sie Zugriff auf ein data-Objekt. Middleman erstellt dann für jede .yml-, .yaml- oder .json-Datei "Objekte", auf die Sie über das anfängliche data-Objekt zugreifen können, indem Sie es verketten. Sie haben dann Zugriff auf die von Ihnen hinterlegten Attribute. In unserem Fall haben wir ein movies YAML-"Objekt" mit den Attributen title, year, text und image.

<%= data.data_file_name.yaml_or_json_object.attribute %>

<%= data.bond.movies.image %>
<%= data.bond.movies.title %>
<%= data.bond.movies.year %>
<%= data.bond.movies.text %>

Wenn Sie Unterverzeichnisse haben, müssen Sie diese nur anheften. Angenommen, Sie haben Ihre Bondfilme-Datendatei in einem spy_movies-Verzeichnis (zum Beispiel: /data/spy_movies/bond.yaml). Sie können jetzt folgendermaßen darauf zugreifen:

1	<%= data.spy_movies.bond.movies.title %>

Zuletzt sollte ich hinzufügen, dass das Speichern in JSON einigen Leuten vorzuziehen ist, aber alle überschüssigen Kommas, Klammern und Klammern schalten mich aus, um ehrlich zu sein. Nicht nur in Datendateien, sondern auch in Frontmatter-Abschnitten. Es liegt natürlich an Ihnen, was am besten zu Ihnen passt. Überzeugen Sie sich selbst:

some_file.yaml:

1	bond_girls:
2	- Strawberry Fields
3	- Jill Masterson
4	- Tiffany Case

some_file.json:

{
  "bond_girls": [
    "Strawberry Fields",
    "Jill Masterson",
    "Tiffany Case"
  ]
}

Hübsche URLs

Wenn Sie eine Datei wie source/bond-movies.html.erb haben, wird sie als https://appname.com/bond-movies.html enden. Während des Build-Prozesses verlieren wir die Dateierweiterung ".erb" und erhalten die endgültige ".html"-Version dieser Seite, die in der URL gespiegelt wird. Das ist in Ordnung, normales Zeug. Für schickere URLs wie http://appname.com/bond-movies müssen wir ein wenig arbeiten.

Sie müssen die Directory Indexes Erweiterung in Ihrer config.rb aktivieren. Dadurch wird für jede .html-Datei ein Ordner erstellt. Während des Mittelsmann-Builds wird die fertige Seite als Indexdatei dieses Ordners angezeigt. Dies bedeutet, dass die Erweiterung als Indexdatei nicht in der URL angezeigt werden muss. Wenn Sie aufgepasst haben, haben Sie dies vielleicht schon bei der Arbeit mit der Standarddatei index.html gesehen, die für jedes Middleman-Projekt als Landingpage erstellt wird. Starten Sie Ihren Server und überzeugen Sie sich selbst.

In config.rb:

1	activate :directory_indexes

Sehen wir uns an, was passiert ist, nachdem der middleman build Ihre bond-movies.html.erb-Datei erstellt hat, wenn Sie diese Erweiterung aktiviert haben. Middleman hat einen Ordner "build/bond-movies" erstellt und Ihr ursprünglicher Dateiname wurde in index.html geändert (build/bond-movies/index.html).

Hier ist die Shell-Ausgabe:

1	create build/bond-movies/index.html

Es gibt jedoch einen kleinen Vorbehalt. Bevor Sie hübsche URLs aktiviert haben, konnten Sie sich auf die Verwendung des Asset-Pfads verlassen. Nachdem Sie nun Verzeichnisindizes eingerichtet haben, müssen Sie Assets mit ihrem vollständigen, absoluten Pfad bereitstellen. Ein Bild nur beim Namen zu nennen, wird also beispielsweise nicht mehr fliegen.

Wenn Sie aus irgendeinem Grund das Verhalten dieser Erweiterung für eine bestimmte Datei überschreiben möchten, können Sie dies tun.

In config.rb:

1	page "/bond-movies.html", :directory_index => false

Hier ist die Shell-Ausgabe, wenn Sie sie wieder für bond-movies.html.erb ändern:

1	create build/bond-movies.html
2	remove build/bond-movies/index.html
3	remove build/bond-movies

Jetzt ist die URL für diese Datei wieder normal.(http://appname.com/bond-movies.html)

Darüber hinaus können Sie das Benennungsschema für Verzeichnisindexe lokal im Frontmater Ihrer einzelnen Seiten deaktivieren:

---
directory_index: false
---

<h1>Bond movies</h1>
...

Wenn Sie diese Struktur mit Ordnern und ihren jeweiligen Indexdateien selbst erstellen möchten, wird Middleman sich nicht mit Ihnen anlegen. Es funktioniert genauso und der Mittelsmann ignoriert sie, wenn Sie diesen Ansatz mischen und anpassen.

Asset-Pipeline

Ich möchte mit diesem hier auf den Punkt kommen und Ihnen nur die Stücke zeigen, die ich für wirklich relevant halte.

Die "Asset-Pipleline" ist Rails-Jargon, der in Middleman importiert wurde. Unter der Haube übernimmt ein Juwel namens Sprockets die ganze schwere Arbeit. Es hilft Ihnen bei der Handhabung des Abhängigkeitsmanagements, beim Kombinieren und Minimieren von Assets, was dazu beiträgt, Ihre Assets erheblich zu reduzieren. Außerdem stehen Ihnen einige Hilfsmethoden zur Verfügung, um prägnant auf Assets zu verweisen. Darüber hinaus haben Sie auch die Möglichkeit, Sass- und CoffeeScript-Code direkt nach dem Auspacken zu schreiben.

Verkettung

Die Verkettung ist eines der wichtigsten Merkmale der Asset-Pipline. Anstatt viele separate HTML-Anforderungen für jede CSS- und JS-Datei zu haben, können Sie sie drastisch reduzieren, indem Sie sie in eine oder eine Handvoll Dateien verketten. Je weniger Anfragen Sie verursachen, desto schneller wird Ihre Anwendung geladen.

JavaScript-Verkettung

Standardmäßig presst Sprockets alle JavaScript-Dateien in eine einzelne .js-Datei. Nach dem middleman build befindet sich diese Datei unter /build/javascripts/all.js. Das gleiche gilt für Ihr CSS. Nach dem Build-Prozess haben Sie alle Sass-Dateien in build/stylesheets/all.css verkettet.

Sie kombinieren Ihre JavaScript-Assets mithilfe von Partials (deren Dateinamen mit einem Unterstrich beginnen) und require sie dann ganz oben in Ihrer Datei source/javascripts/all.js. Dateien mit einer hinzugefügten .coffee-Erweiterung funktionieren genauso. Für diesen Prozess spielt die Reihenfolge eine Rolle.

Hier ist zum Beispiel der Anfang von source/javascript/all.js:

1	//= require "_jquery"
2	//= require "_lib_code"
3	//= require "_animations"

Wenn Sie in Ihr neues /build-Verzeichnis schauen, finden Sie unter /javascripts nur eine .js-Datei.

CSS-Verkettung

Für Ihren Sass-Code ist die Story im Wesentlichen dieselbe, aber Sie sollten Sass @import zum Importieren Ihrer Partials verwenden, anstatt sie von Sprockets zu require. Platzieren Sie wieder die "erforderlichen" Dateien ganz oben, diesmal auf die Reihenfolge achten. Im Gegensatz zu JavaScript-Partials lassen Sie den Unterstrich weg, wenn Sie Sass-Partials importieren. Beispielsweise

1	@import 'normalize';
2	@import 'header';
3	@import 'navigation';
4	@import 'footer';

Kompression (Minimierung)

Ein weiteres cooles Feature von Kettenrädern ist die Kompression, auch Minimierung genannt. Dieser Prozess spart viel Fett, wie das Entfernen von unnötigem Leerraum und Kommentaren. Die Leute nennen diesen Prozess auch hässlich (und natürlich gibt es einen Edelstein namens uglifier, der das wunderbar macht). Im Vergleich zur JavaScript-Asset-Minifizierung ist die CSS-Uglifizierung nicht so kompliziert.

Um zu beginnen, müssen Sie Ihrer Datei config.rb Folgendes hinzufügen:

1	configure :build do
2	activate :minify_css
3	activate :minify_javascript
4	end

Eigentlich müssen Sie diese Zeilen nur unter Ihrem :build-Block auskommentieren. Wenn Sie das nächste Mal einen middleman build verwenden, werden die Assets in Ihrem /build-Ordner alle hässlich und schlank sein. Unten sind zwei kleine Beispiele, wie dieser Code tatsächlich aussieht:

Verkleinertes CSS unter /build/stylesheets/all.css:

1	body{background-color:#d0e4fe}h1{color:orange;text-align:center}p{font-family:"Times New Roman";font-size:20px}

Minimiertes JS unter /build/javascripts/all.js:

switch((new Date).getDay()){case 0:day="Sunday";break;case 1:day="Monday";break;case 2:day="Tuesday";break;case 3:day="Wednesday";break;case 4:day="Thursday";break;case 5:day="Friday";break;case 6:day="Saturday"}

Ohne die Asset-Pipleline müssten Sie Ihr eigenes Ding einrichten, um Ihr JavaScript und CSS über höhere Sprachen wie CoffeeScript und Sass zu schreiben.

Asset-Pipeline-Helfer

Für Ihre Sass-Dateien stehen Ihnen vier Helfer zur Verfügung:

image_path()
font_path()
image_url()
font_url()

Da Sie bisher die Konventionen befolgt haben, können Sie mit diesen Hilfsprogrammen den richtigen Verzeichnispfad zu Ihren Assets voranstellen.

In einer Sass-Datei zum Beispiel:

image_path('logo.png')
# => images/logo.png

image_path('nested_folder/some.png')
# => images/nested_folder/some.png

Importpfad

Die Asset-Pipeline verwendet Importpfade über Sprockets für Ihre Assets. Standardmäßig werden diesem Pfad bereits :js_dir und :css_dir hinzugefügt. Das bedeutet, dass Dateien in /source/javascripts und /source/stylesheets verfügbar sind und automatisch importiert werden. Wenn Sie andererseits Assets haben, die Sie in anderen Verzeichnissen behalten möchten, können Sie sie auch zum Importpfad hinzufügen, indem Sie config.rb bearbeiten:

1	sprockets.append_path '/some/other/assets_folder/'

In diesem Beispiel stehen Middleman über diesen Pfad auch andere Assets in source/some/other/assets_folder/other.css zur Verfügung. Das gleiche gilt auch für .js-Dateien.

Projektvorlagen

Middleman enthält ein paar praktische Projektvorlagen, die Sie zumindest kennen sollten. Diese Vorlagen bieten Ihnen einen guten Ausgangspunkt, wenn Sie eine neue Middleman-App initiieren. Sie können diese Vorlagen auch später jederzeit hinzufügen:

SMACSS-Vorlage
Vorlage für mobile Kesselplatten
HTML5-Boilerplate-Vorlage
Blog-Vorlage (benötigt zusätzlichen Edelstein)

Sie können sie wie folgt über die Befehlszeile verwenden:

1	middleman init your_fancy_app --template=smacss

Die Vorlage stellt Ihnen alle benötigten Dateien und Ordner zur Verfügung. Wenn Sie bereits eine App haben und eine Vorlage hinzufügen möchten, verwenden Sie denselben Befehl, ohne den Namen Ihrer App zu erwähnen. Gleiches Angebot:

1	middleman init --template=smacss

Jetzt kommt mein Lieblingsteil von Middleman. Es ist super einfach, Ihre eigenen Vorlagen zu erstellen und sie jederzeit wiederzuverwenden. Sie erstellen zunächst einen Ordner ~/.middleman in Ihrem Stammverzeichnis (vergessen Sie den Punkt vor dem Namen nicht). Innerhalb dieses Verzeichnisses erstellen Sie neue Ordner für Ihre Vorlagen. Zum Beispiel wäre /.middleman/podcast eine podcast-Vorlage. Dann füllen Sie dieses Podcast-Verzeichnis mit allen benötigten Dateien und Ordnern. Wenn Sie beispielsweise zusätzliche Stylesheets für Ihre Middleman-App verfügbar haben möchten, müssen Sie den Dateipfad von Middleman simulieren, um die Verwendung sehr einfach zu machen.

Im Screenshot unten habe ich ein Dummy-Beispiel vorbereitet, das ein paar Dateien enthält, die ich möglicherweise für jedes Projekt in einem "bourbon"-Ordner benötige. Jetzt habe ich eine Bourbon-Vorlage.

Da ich die Dateistruktur von Middleman simuliert habe, werden diese Stylesheets genau dort angezeigt, wo ich sie brauche, nachdem ich diese Vorlage gestartet habe. Meine Dateien befinden sich jetzt unter /source/stylesheets und können auch in meine Datei /source/stylesheets/all.css.scss importiert werden.

Da ich meine Vorlagenstile bereits teilweise erstellt habe, läuft es wie gewohnt. Hier ist meine Quelle/stylesheets/all.css.scss:

1	@import 'bourbon_mixins/mixins';
2	@import 'bourbon_neat/grids';
3	@import 'bourbon_refills/cards';
4	...

Fertig! Eines sollten Sie jedoch beachten: Wenn wir middleman build verwenden, um unser neues build-Verzeichnis zu erstellen, werden diese Dateien von all.css absorbiert und keiner der Bourbon-Vorlagenordner wird dort angezeigt. Wenn Sie jedoch vergessen, einen führenden Unterstrich in Ihren Dateinamen für diese Stile zu verwenden, wird der gesamte Ordner zusammen mit den entsprechenden .css-Dateien nach /build übertragen. Auch die @import-Anweisungen in all.css.scss machen in diesem Fall keinen Unterschied.

Nach Vorlagen suchen

Wenn Sie eine Menge Vorlagen haben und nur die Liste nach einem Namen durchsuchen möchten, können Sie den folgenden Befehl verwenden:

1	middleman init --help
2
3	# => # Use a project template: default, html5, mobile, smacss, bourbon

Wenn Sie das Rad neu erfinden möchten, werfen Sie einen Blick auf diese Open-Source-Vorlagen. Wenn Sie noch nie viel mit Vorlagen gespielt haben, empfehle ich Ihnen, eine Dummy-App zu starten und sie auszuprobieren. Sehen Sie, welche Dateien erstellt oder überschrieben werden. Stöbere ein bisschen herum. Erstellen Sie dann einen Dummy-Ordner mit ein paar Sass-Dateien für eine Vorlage unter ~/.middleman und sehen Sie, was passiert, wenn Sie diese Vorlage starten. Nichts geht über das Lernen durch diese kleinen Experimente auf dem Weg!

Abschließende Gedanken

Ich glaube, Sie sind jetzt mehr als bereit, mit Middleman eine kleine App zu erstellen. Es gibt noch ein paar Dinge, die du selbst lernen musst, aber ich habe dir die wichtigsten Teile des Puzzles vorgestellt.

Middleman macht viel Spaß und ist technisch eine gute Wahl. Es ist leistungsstark, einfach zu bedienen und verfügt über eine einfache API, die anfängerfreundlich ist. das ist alles, was jetzt zählt. Habe Spaß!