Symfony und das Dojo Build System

Das Dojo Toolkit bietet neben den offensichtlichen Features eines Full-Stack-Frameworks unter anderem mehrere “environment aware” Debug-Modi und eine Sammlung vonBuild-Scripten, die es dem Entwickler erlauben, das Framework zusammen mit den eigenen Frontend-Scripten und Stylesheets zu “kompilieren” und somit Bandbreite zu sparen bzw. Ladezeiten zu minimieren.

Dojo Baukausten

Standardmäßig lädt der Dojo-Core alle benötigten Pakete, die mittels dojo.require() angefordert werden, via XmlHttpRequest vom Server. Das kann je nach Projektumfang schonmal einige Sekunden in Anspruch nehmen, wenn plötzlich gefühlte 200 Sub-Requests beim Pageload abgefeuert werden.

Wenn es generell ans Deployment eines Web-Projekts geht, ist man daran interessiert, die Ladezeit von Scriptdateien oder Stylesheets zu minimieren, indem man zum Beispiel im ersten Schritt alle referenzierten Script-/CSS-Dateien in eine große Datei überträgt und damit konsolidiert. Dies kann mitunter mit Aufwand verbunden sein, wenn viele Scripte copied & pasted werden müssen, außerdem scheint diese Vorgehensweise nicht besonders elegant, noch dazu Fehleranfällig.

Im zweiten Schritt nutzt man üblicherweise so etwas wie Code-Obfuscating oder Code-Minimizing. Diese Techniken dienen in erster Linie dazu, die Datenmenge von Script-Quellen zu minimieren und damit die Downloadzeiten zu beschleunigen. Dies geschieht wiederum mit Hilfe von Shellscripten oder Mini-Programmen, die Quelltexte parsen und dann je nach Voreinstellung White-Spaces und Kommentare entfernen oder den ganzen Code überarbeiten, indem bspw. Variablennamen durch möglichst kleine Buchstabenkombinationen ersetzt werden um die Zeilenlänge zu begrenzen. Der Betrachter sieht dann in der Quelltextansicht nur noch eine lange, einzeilige “Code-Wurst”.   “Disassembling” ist hier nur mit Aufwand möglich, aber prinzipiell eben das: möglich.

Die Dojo-Build-Tools automatisieren beide Schritte, wobei Schritt 1, die Code-Konsolidierung, durch das Dojo-Pakagesystem ermöglicht wird und Schritt 2 durch einen eingebauten Obfuscator, alternativ kann der Google Closure Compiler verwendet werden. Die Werkzeuge bestehen aus einigen .jar-Dateien, die in jeder halbwegs aktuellen Java Virtual Machine laufen und mittels $ java –classpath … aufgerufen werden. Ein paar freundlicherweise beigelegte Shellscripte bzw. .bat-Dateien vereinfachen den Aufruf.

Die Datei build.sh beispielsweise benötigt mindestens einen Zielparameter “profile”, der den Pfad zur Profildatei enthält. Diese Datei besteht aus einem JSON-Objekt und konfiguriert die Projektumgebung. Hier kann der Entwickler alle Dateien bzw. Namensräume angeben, die der Compiler berücksichtigen soll.

Optional anzugeben ist die Behandlung von CSS-Dateien, die Code-Minimierungsstrategie und so weiter. Ein $ build.sh liefert eine gut dokumentierte Liste der möglichen Argumente.

Somit lassen sich automatisiert alle eigenen Javascripts und die des Dojo Frameworks zusammen mit CSS-Stylesheets für die Produktionsumgebung “fit machen” und optimieren. Dokumentiert ist das ganze wie immer mäßig auf dem dojocampus.

Dojo und Symfony

Im Entwickleralltag möchte man seine Entwicklungsumgebungen zentral verwalten. Im Symfony-Kontext gibt es bspw. standardmäßig die Environments “Prod”, “Int” und “Dev”. Alle drei Umgebungen nutzen unterschiedliche Datenbanken, Loggingeinstellungen und so weiter. Natürlich liegt es nahe, die einzelnen Dojo-Builds ebenfalls “environment-aware” zu konfigurieren. Dies ist mit einigen einfachen Schritten erledigt, so könnte man bspw. das Script-Verzeichnis umgebungsabhängig verwalten. Doch so richtig optimal ist das nicht, und vor allem: Die Dojo-Build-Tools haben in der Form keine Entsprechnung als Symfony-Task, die Verheiratung wirkt also etwas widerwillig.

In so einem Fall lohnt sich natürlich der Blick ins Symfony Plugin Repository, und siehe da, das sfDojoPlugin erledigt den Job. Installieren, Dojo als Dependency herunterladen (ein großer Vorteil, somit ist man nicht auf eine eventuell veraltete bundled Version angewiesen), Filter einfügen, fertig. Schon gibt es einen neuen Symfony Task Namespace “dojo”.

$ symfony dojo:build-for-prod

kompiliert dann die Javascripts für die Produktionsumgebung, ohne dass zusätzlicher Konfigurationsaufwand anfällt. Das ganze funktioniert durch eine Namensraum-Konvention der Ordner, in denen das Plugin einerseits die Dojo-Sourcen erwartet und andererseits die komplierten Scriptdateien ablegt.

Ein weiteres Killer-Feature ist das einfache Injizieren von PHP-Variablen in den Javascript-Context, das hier weitestgehend automatisiert abläuft. Interessant in diesem Zusammenhang wäre vielleicht noch zu wissen, in wie weit die I18N-Features des Symfony-Frameworks mit denen der Dojo-Welt verheiratet sind.

Dojo passt also ab Werk bereits hervorragend in jedes Symfony-Projekt, und mit dem sfDojoPlugin lässt sich die Integration nahtlos bewerkstelligen. Hat man sich einmal an die schlechte Dokumentation und die wirklich steile Lernkurve gewöhnt, lässt man mit Dojo meiner Meinung nach in Punkto Stabilität, Funktionsumfang und Projektunterstützung erstmal so ziemlich alles andere hinter sich.

Links

Dojo Toolkit: http://www.dojotoolkit.org/

sfDojoPlugin: http://www.symfony-project.org/plugins/sfDojoPlugin

Eine Beispielimplementierung einer Webbasierten GUI-Komponente für die Build-Tools, leider auf Basis einer veralteten Version : http://build.dojotoolkit.org/0.4.2/web/buildscripts/webbuild/

Ebenfalls veraltet, aber sicher einen Blick wert: GUI für die Dojo Build Tools, Eclipse-basiert: http://shaneosullivan.wordpress.com/2007/01/29/second-beta-of-dojobuilder-released/