Natürlich spricht nichts dagegen, das Script als Vorlage für seinen eigenen genererate-bootstrap-code zu modifizieren.

Damit hole ich die HEAD Rev oder ein stable tag aus SVN, mach noch ein paar Fileoperations, wie Live Configs reinkopieren, .htaccess vorbereiten etc.
und jage die files dann, für die Standard Hosting Packete, mit FTP hoch. Dabei benutze ich noch die timediffauto Option, um nur die geänderten Files hochzuladen.

Nachdem wir hier den DeployServer neu gemacht haben, schmiess der FTP Task allerdings eine NullPointerException, die ich mir nicht erklären konnte, eigentlich war alles wie vorher.
Letztlich konnte ich es dann auf das timediffauto Attribut einkreisen und nach langem grübeln und googeln dann die Lösung:

Wir haben ein deutsches Debian Lenny installiert, das war vorher nicht so, sondern Englisch.
Die meisten Hosting Server scheinen auch Englische zu sein und da kam Ant ins straucheln.

Dank dieses Post hab ich dann die build.xml angepaßt und diese Attribute eingefügt:

serverLanguageCodeConfig="en" 
shortMonthNamesConfig="jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec"

Wie es auch hier steht: http://ant.apache.org/manual/OptionalTasks/ftp.html

Fertig sieht der Task dann so aus:

<target name="startFTPTest" depends="check-cond" if="test">
		<move file="${updateChannelTemp}/${SvnExportDir}/.test.htaccess" tofile="${updateChannelTemp}/${SvnExportDir}/.htaccess"/>
		<ftp server="${ftpSite}" userid="${ftpUsername}" password="${ftpPassword}" serverLanguageCodeConfig="en" shortMonthNamesConfig="jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec" remotedir="${remoteDirTest}" action="send" verbose="yes" passive="yes" depends="yes">	
			<fileset dir="${updateChannelTemp}/${SvnExportDir}" includes="**/*.php,**/*.css,**/*.html,**/*.js,**/*.gif,**/*.png,**/*.jpg,**/*.htaccess" excludes="**/install/**,**/configure.php**,**/*.test.htaccess">
			</fileset>
		</ftp>
</target> 

und dann lief es wieder.

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/

Eine sehr nützliche Seite, die eigentlich nur eine Checklist ist.

Check if your symfony application is ready for deployment

Aber schön gemacht und sehr nützlich.

Wie oft hab ich schon vergessen die ErrorPages zu customizen.
Oder schön ist auch wenn man ne Email kriegt “Du benutzt symfony, richtig?”, weil man vergessen hat die Cookie Names anzupassen.