Weblog von Wolfgang Hauertmann

Es gibt viele Möglichkeiten in Grunt, Dateien zu kopieren und das Kopieren von Dateien ist eine der häufigsten Operationen bei der Automatisierung. Deshalb sollte man sich frühzeitig mit einigen grundsätzlich verschiedenen Möglichkeiten vertraut machen. Die folgenden fünf Beispiele wurden so ausgewählt und gestaltet, dass sie ihren typischen Einsatzbereich andeuten und man sie für ihren praktischen Einsatz mit Copy & Paste übernehmen und leicht an die eigenen Bedürfnisse anpassen kann.

Grunt ist ein Tool, welches Aufgaben (Tasks) in erster Linie synchron ausführt und das ist für ein Automatisierungstool die wichtigste Fähigkeit. Es ist es keine triviale Eigenschaft, weil Grunt naturgemäß mit fremden Shells zusammenarbeitet und von gestarteten Anwendungen Informationen darüber benötigt, wann und wie eine Aufgabe tatsächlich fertiggestellt wurde. Nicht immer gelingt dies Grunt mit seinen Bordmitteln, so dass manchmal nachgeholfen werden muss (z.B. bei dem unter Windows sehr interessanten Kopier-Programm Robocopy, für das es deshalb ein eigenes Grunt-Module grunt-robocopy gibt).

Grunt bietet aber auch die Möglichkeit, Aufgaben asynchron zu verarbeiten. Wer diese Möglichkeiten nutzen will, kommt schnell in Schwierigkeiten, wenn er nicht richtig verstanden hat, wie Grunt hierbei vorgeht. Es ist eine gute Übung, sich mit diesen Möglichkeiten zu Beginn der Einarbeitung mit Grunt zu beschäftigen, da man sich hier ein solides Grundverständnis für das Arbeiten mit diesem Automatisierungstool erarbeiten kann.

Wer ein Grunt-Skript für seine Automatisierungsaufgaben erstellt, benötigt schnell einen Debugger mit leistungsfähiger GUI, z.B. den Entwicklertool des Chrome-Browsers. Leider gilt wie immer, dass Grunt auf Linux entwickelt wurde und deswegen die Debugging-Möglichkeiten unter Windows etwas hakeln oder die vorgeschlagenen Lösungen im Netz nicht für Windows funktionieren. Im folgenden wird gezeigt, wie man unter Windows mit dem Chrome-Entwicklerwerkzeug arbeiten kann, um seine Grunt-Skripte zu debuggen.

ImageMagick ist ein ToolKit, das im Gegensatz zur PHP-Standard-Grafikbibliothek GD auch gif, png und andere Bild-Formate unterstützt. In Drupal z.B. wird es vom Image-Modul verwendet, mit dem Uploads von Bildern in Thumbnails und geeignete Größen umgewandelt werden können. Mein Hoster unterstützt diese Bibliothek, so dass ich darauf aufsetzende Module einsetzen kann.

Für die lokale Entwicklung muss ich ImageMagick unter Windows installieren. Das Hauptproblem dabei ist, dass vom Distributor und von PHP-Extension-Entwicklern verschiedene Compilierungen angeboten werden, die zueinander passen müssen.

In diesem Artikel wird ein leicht nachvollziebares Grundgerüst für die Automatisierung eines einfachen Workflows für das Deployment eines Web-Projekts mit Hilfe von Grunt.js unter Windows vorgestellt. Dabei wird nur die Grundstruktur implementiert, so dass spezielle Anforderungen, wie z.B. Minification, SASS-Compilierung, die Unterstützung von Test-Driven-Design oder Mobile-Cross-Platform-Development vom Entwickler je nach seinen speziellen Bedürfnissen hinzugefügt werden können.

Eine einfache Möglichkeit in Drupal Popup-Fenster zu erzeugen, bietet das Drupal-Modul Colorbox, das auf dem gleichnamigen jQuery-Plugin basiert.

Dies wird in folgendem Beispiel anhand eines einfachen Szenarios gezeigt.

Bei einem größeren Projekt entstehen höhere Anforderungen an die Organisation und Dateistruktur der Sourcen. Diese Anforderungen gelten sowohl für die Modul- als auch die Theme-Entwicklung. Dazu muss man sich in jedem Projekt Gedanken machen,

• wie man den Source-Code innerhalb eines Moduls oder Themes auf verschiedene Ordner und Dateien verteilt,
• wie man Teile des Source-Codes über mehrere Module hinweg gemeinsam nutzen kann und
• wie man Ordner-, Datei-, Klassen- und Funktionsnamen so wählt, dass der Source-Code am Ende gut lesbar ist.

Drupal bietet hierfür verschiedene gestufte Ansätze, die je nach Komplexität des Projekts mehr oder weniger in Frage kommen. Insbesondere empfiehlt es sich, bei jedem nicht-trivialen Projekt das Autoloading zu nutzen.

Im folgenden werden die Möglichkeiten der Sourcecode-Strukturierung in Drupal kurz diskutiert, um dann ausführlicher auf das PSR-4 Autoloading einzugehen, das für Drupal 8 den aktuellen Standard darstellt und für das es in Drupal 7 das Modul X Autoload gibt.

Wer häufiger mal einen View gebaut hat, wird auf dieses Problem gestoßen sein: Für einige Felder des Views werden keine Daten ausgegeben.

Meist liegen die Ursachen in einer fehlerhaften Konfiguration. Gerade in Drupal sind aufgrund des aspektorientierten Ansatzes Konfigurationen für das gleiche Objekt häufig in verschiedenen Modulen vorzunehmen, so dass man leicht den Überblick verliert. Meist stößt man nach einiger Zeit auf die Lösung, allerdings eben gerade nicht, wenn man verzweifelt danach sucht.

Bis dahin kann man sich mit folgendem Provisorium helfen.

Wer ein etwas komplexeres Modul erstellt, wird seinen Source-Code dafür in der Regel auf mehrere Ordner und Dateien aufteilen. Diese Ressourcen müssen an der richtigen Stelle geladen werden. In der Drupal-Dokumentation wird hierfür die Funktion module_load_include empfohlen. Die Anwendung führt aber manchmal zu Problemen, die im folgenden dargestellt werden.

Wer ein Portal entwickelt, benötigt Test-Content. Drupal stellt hierfür im Rahmen seines Devel-Moduls das leistungsfähige Sub-Modul Devel Generate zur Verfügung.

Damit lassen sich Lore Ipsum-Texte, Random-Bilder (s. Bild links), Lore Ipsum-Taxonomien sowie Inhalte für alle Felder für alle Content-Typen erzeugen.

Die Flexibilität dieses Moduls reicht allerdings nicht aus für anspruchsvollere Konfigurationen und Entwicklungen. Dafür sind programmtechnische Eingriffe erforderlich.