Aufbau des Frameworks in der Theorie, Teil 1 - Controller

Die Controller sind das Bindeglied zwischen den Views und dem Model. Darum wird dieser Teil der wahrscheinlich meistgenutzte sein.

Die Grundidee des Controllers in einem Webframework ist das Binden eines Callbacks an eine Route und die Benennung dieser Routen auf Basis von Konventionen, basierend auf den Entitäten, die im Model definiert werden. Dabei arbeiten wir in einer REST-Architektur, so dass sich allein durch den Namen des Models schon alle Actions als Routen ableiten lassen.
Klingt kompliziert, ist es aber gar nicht. Nehmen wir im einfachsten Fall an, wir erstellen ein Model namens Post, welche die Properties "title" und "body" erhält.
Der Controller zu diesem Modell würde dann also der posts-controller sein und standardmäßig Actions für das Erstellen, Bearbeiten, Anzeigen und Auflisten von Posts zur Verfügung stellen.
Da wir nach dem REST-Prinzip arbeiten, wissen wir schon wie Routen auszusehen hätten, nämlich:

• Auflisten: GET /posts
• Anzeigen von post mit der id 1: GET /posts/1
• Erstellformular: GET /posts/new
• Erstellen: POST /posts
• Bearbeiten-form für post 1: GET /posts/1/edit
• Änderung an post 1 speichern: PUT /posts/1
• Löschen-Seite für post 1: GET /posts/1/delete
• Löschen von post 1: DELETE /posts/1

Ich habe mich dazu entschieden den Ruby-Webserver Thin zur Auslieferung zu nutzen, der alle Http-Methoden der Rest-Architektur voll unterstützt und voll kompatibel zur Rack, einem Ruby-Interface zu Webservern, ist.

Nun müsste man nur noch auf Basis von Rack ein Framework erstellen, dass die Handler für die Methoden bequem aufrufen und an Callbacks hängen lässt, welche die benötigte Template-Engine zum Rendering beherscht.

Das haben sich andere schlaue Köpfe bereits überlegt, in Code umgesetzt und das ganze Sinatra genannt. Sinatra stellt ein Microframework in Form einer Domänen-spezifischen Sprace zur Verfügung. Ich werd hier nicht tiefer auf die Funktionsweise und irgendwelche "Hello-Worlds" eingehen, da die ReadMe von Sinatra, die für Englisch-Muffel auch ins Deutsche übersetzt wurde, das bereits ganz hervorragend erledigt.

Wie wir in zukünftigen Posts sicher noch sehen werden, ist Sinatra wunderbar zu erweitern, was dem erstrebten DRY-Prinzip sehr entgegenkommt.

So wundert es nicht, dass ich mit Sinatra-Resources bereits eine Erweiterung ausgemacht hab, mit dem sich das Resourcen-basierte Prinzip der MVC-Arbeitsweise hervorragend umsetzen lässt.

Was der Abtrennung der einzelnen Controller voneinander bekömmlich ist, ist die Möglichkeit der Modularisierung in Sinatra. Damit können wir Klassen schreiben, die sich von Sinatra::Base ableiten und haben damit die Möglichkeit Controller tatsächlich auf Basis ihres zu Grunde liegenden Models zu benennen und in eigene Dateien zu stecken.

Ein weiterer Aspekt der Sinatra zur Auswahl verhalf ist die Unterstützung aller möglichen und unmöglichen Rendering-Engines, die im Webberreich vorhanden sind, welche sich wiederum relativ einfach erweitern lässt. Da ich als Template-Engines Haml und Sass für HTML und CSS und eventuell Coffeescript für Javascript einsetzen werde, ist eine Erweiterung aber eigentlich nicht notwendig.

Damit sind wir auch schon bei den Views, zu denen nicht allzuviel zu sagen ist. Die Views stellen das Interface zwischen User und Controller dar und werden im Webbereich eben von HTML, CSS und Javascript dargestellt.

Will man DRY arbeiten, macht es Sinn in allen drei Bereichen Renderengines einzusetzen. Im HTML-Bereich ist die Templateengine der Wahl dabei einfach HAML, da dieses das Dry-Prinzip sogar bis in den HTML-Bereich überträgt und aufgrund der Struktur und Funktionalität besser für das Templating geeignet ist als beispielsweise Markdown, welcher in der Textgestaltung ganz hervorragend ist.

SASS macht das gleiche sogar für CSS und kommt auch aus der gleichen Schmiede. Früher war es sogar im gleichem Rubygem integriert.

Bei den Überlegungen in Richtung Coffescript, einer kleinen Sprache, die nach Javascript kompiliert wird, geht es weniger um DRY als um die Erhöhung der Lesbarkeit des Javascript-Codes. Insbesondere wenn man, wie ich, im Team mit reinen Webdesignern und Projektleitern/Systemarchitekten arbeitet ist verständlicher Code von nicht unerheblicher Bedeutung.

Umso leichter Code zu lesen ist, desto einfacher wird es eben Nichtentwicklern klarzumachen, was man an bestimmten Stellen aus welchen Grund tut.

Zum Theorieteil wird es mindestens noch zwei Teile geben. Einer wird sich mit den Modellen an sich und dafür  geeigneten Libraries auseinander setzen. Beim Zweiten wird es sich um Unittesting, dessem Sinn und der dafür eingesetzten Library drehen.

Selbstverständlichen wird es auch praktische Teile geben. Genaugenommen werden diese mittelfristig sogar den Hauptteil des Blogs ausmachen. Den Code sagt oft mehr als Bilder und die sagen ja bekanntlich schon mehr 1000 Worte.