Sofort dachte ich mir aber: Dann bin ich ja monatelang damit beschäftigt, den Code von NoseRub kompatibel mit Cake 3 zu bekommen…

Das mag zwar ein wenig Panikmache sein, denn noch ist überhaupt nicht klar, wie die Umstellung auf Cake 3 laufen soll, aber ich mache mir trotzdem schon einmal Gedanken dazu, wie man die Umstellung möglichst reibungslos hinbekommt.

Ich denke mal, dass Tests der Schlüssel zum Erfolg sind. Dabei sind jedoch nicht nur Unittests gemeint, sondern auch Tests mit Selenium um die Funktionalität überprüfen zu können.

Da kommt noch eine ganze Menge Arbeit auf mich zu…

Gleichzeitig werde ich die Artikel auch auf Englisch veröffentlichen. Meistens wahrscheinlich mit einem kleinen Zeitverzug werden sie dann unter CakeBakery.net erscheinen.

Das solltet ihr aber wirklich nicht tun!

Mit einem Kollegen hatte ich darüber viele Diskussionen, weil ich auch lieber direkt das SQL angegeben habe, aber dann brachte er irgendwann das ultimative Argument:

Du umgehst damit beforeFind() und afterFind()!

Das war’s. Das ultimative Argument. Denn er hat Recht.

Stellt euch vor, dass ihr in afterFind() eines Models die gefundenen Daten zusätzlich anreichert. Sei es ein einfaches name, welches sich aus Vor- und Nachname zusammensetzt, oder andere, beliebig komplexe Dinge.

Wenn ihr nun mittels query() Daten aus diesem Model holt, fehlen die zusätzlichen Felder. Die Folge wird sein, dass euer Code Fehler produziert.

Macht euch also lieber die Arbeit und setzt euch mit find() auseinander. Dabei lernt ihr nicht nur eine Menge über CakePHP, sondern habt im Ergebnis auch besser wartbaren Code.

Sämtliche find-Methoden aus Cake (auch findCount() und read()) benutzen diese Informationen, um verbundenen Models zu holen. Grundsätzlich eine prima Sache, aber bei komplexeren Datenstrukturen und Rekursionslevel von 2, kann da ein einfaches find() ganz schön viel Daten zurückliefern.

In der Praxis behilft man sich dann meistens mit unbindModel() und bindModel(). Hat man in seinen Models alle Relationen aufgeführt, benutzt man vor jedem find() ein unbindModel() um überflüssige Models zu entfernen. Der andere Weg wäre, die Relationen im Model ganz weg zu lassen und dann jeweils gezielt mit bindModel zu spezifizieren, welche Models benötigt werden.

Letzeres ist aber nicht wirklich erstrebenswert, weil damit in der Applikationslogik verborgen ist, wie die Models untereinander verbunden sind. Bliebe also nur, die unnötigen Models vor einem find() mit unbindModel() zu entfernen. Das ist aber dann problematisch, wenn in die Applikation immer mal wieder neue Models und Relationen eingepflegt werden. Denn dann müsste man diese neuen Relationen bei Bedarf (bzw. Nicht-Bedarf) in den unbindModel()-Aufrufen ebenfalls nachpflegen.

Alles in allem also irgendwie ziemlich unbefriedigend. Das hat sich auch Mariano Iglesias gedacht und expects() erdacht. Mit expects() hat man die Möglichkeit genau zu spezifizieren, welche Models beim nachfolgenden find() geholt werden sollen. Es ist damit nur eine andere Notation für bindModel() und undbindModel(). Aber wesentlich einfacher gehalten, da in den Models weiterhin die Art der Relation (belongsTo, hasMany, etc.) spezifiziert wird und mittels expects() nur noch die in der Rückgabe erwarteten Models spezifiziert werden.

expects() wird im AppModel eingefügt, man bleibt damit also unabhängig von CakePHP selbst, was einem regelmäßige Updates von CakePHP erleichtert.

Bei oben verlinktem Beitrag zu expects() sollte man unbedingt auch die Kommentare lesen, weil sie noch ein paar wichtige Fragen und Hinweise enthalten.

Dazu kann ich jedem YAML – Yet another Multicolumn Layout (nicht zu verwechseln mit dem Markup) von Dirk Jesse empfehlen. Dies ist ein ‘CSS-Framework’, das als Grundbaustein für allerlei Spaltenlayouts einzusetzen ist und eine Menge Arbeit spart, wenn man sich an die dazugehörigen Konventionen hält. Die Dokumentation des Frameworks ist sehr ausführlich und erklärt die vielen CSS Probleme und Stolperfallen ausführlich. Selbst, wenn man YAML nicht einsetzen möchte, lohnt sich das Lesen. Zudem hat Dirk Jesse gerade sein Buch ‘CSS Layouts – Praxislösungen mit YAML’ bei Galileo veröffentlicht.

Allen Bakern einen guten Rutsch und viel Erfolg im kommenden Jahr.

Update: Mein Dank geht an dieser Stelle nochmal an Ansgar Hein und Jens Grochtdreis, die mir YAML auf einer Barcamp Session in Köln nähergebracht haben. Im Frühjahr wird es im Übrigen wieder ein Barcamp in Deutschland geben, diesmal in Frankfurt: Barcamp – Frankfurt.

Denn im Header-Bereich seiner Seite wurde extra ein Link für ein Favicon definiert, welcher auf favicon.ico zeigt und nicht etwa /favicon.ico. Dieser kleine Unterschied hat eine große Auswirkung, denn der Browser versucht nun, in jedem Unterverzeichnis ein Favicon zu finden.

Und wenn man in CakePHP so schön mit netten URLs arbeitet (das ist keine Kritik an den Nice-URLs!), steht im Browser oft sowas hier: http://mein-cooles-projekt.de/produkte/neu/. Für den Browser ist das ein Verzeichnis und so versucht er, aus /produkte/neu/ das Favicon zu laden. Aufrgrund der Verarbeitung der Routen in CakePHP wird dabei aber erneut die Controller-Action aufgerufen, darin wieder die Seite gerendert, nochmal ein Link auf das Favicon gesetzt, usw.. Warum der Controller nun genau drei Mal aufgerufen wird, kann ich nicht genau sagen. Vielleicht ist dies dann auch nur eine Race-Condition, die eine Endlosschleife verhindert.

Beobachtet habe ich dieses Verhalten übrigens mit dem Firefox und auf die Schliche gekommen bin ich letztendlich mit der wunderbaren Erweiterung Live HTTP Headers.

Gelöst werden kann das Problem auf zwei Arten: entweder man verzichtet gänzlich auf die Favicons und löscht die entsprechende Zeile aus layout/default.html. Oder man fügt ein / vor favicon.ico ein. Dann sucht der Browser nur im Document-Root nach dem Favicon.

Als ich letztes Jahr anfing CakePHP zu nutzen, gab es da schon einen Helper für Ajax eigentlich insbesondere für Prototype. Leider hatte ich immer das Problem, dass der nie genau das tun wollte, was ich gerade vorhatte. Zum Beispiel gab es damals noch keine saubere Umsetzung ein Formular per Ajax abzuschicken, aber genauso ohne Javascript zu funktionieren. Heute findet man auch im trac etwas zu ‘degradable ajax’.

Das ändert aber nichts daran, dass die Javascript Generierung nach wie vor nicht alle Möglichkeiten bietet und das HTML mit Script-Blöcken und hart codierten Eventhandlern durchsetzt. Was wenn ich eine Applikation bauen möchte, in der CSS und Javascript ‘degradable’ sein sollen, sehr unschön ist. Dieses Problem zu lösen würde mir ein Maximum an Usability und gleichzeitiger Accessibility bieten.

Davon abgesehen ist die Pflege des Javascript Codes schwierig, wenn die Funktionen über viele Views hinweg verstreut in der Gegend herum liegen. Da wird es auch schwer sein Javascript test-getrieben zu entwickeln. Ich war zwar froh mit CakePHP ein Framework gefunden zu haben, mit dessen Konventionen ich sehr gut leben und meinen PHP Code besser strukturieren kann, aber das Javascript ist und bleibt chaotisch.

Was also, wenn ich mein Javascript komplett von meinen Templates trennen möchte? Wieso ist mein Javascript nicht auch nach MVC getrennt? Warum übertrage ich nicht einfach die Ideen aus Rails und CakePHP auf mein Javascript?

Diese Fragen schwirrten lange in meinem Kopf herum. Mittlerweile habe ich mir ein rudimentäres Javascript Framework geschrieben, der größte Dank geht dabei an jQuery! Mit jQuery kann ich mein Javascript komplett vom HTML trennen ohne für jedes Element Ids vergeben zu müssen. Die Notation ist ähnlich wie bei Prototype über $(), jedoch kann man anstelle der Id auch eine CSS ähnliche Notation verwenden (das hat uns ja auch schon behaviour gezeigt). jQuery ist mit 17kb recht kompakt, performant und bietet neben Ajax, Effekten und Eventhandling die Möglichkeit recht schicke Plugins zu schreiben.

Derzeit habe ich also bei einer Cake Applikation kein einziges ‘onclick, onsubmit usw.’ und ausser den im Head eingebundenen Javascript Dateien keinen weiteren Skript-Block in meinen Views. Die Initialisierung des Javascripts läuft, nach dem Laden des DOMs über jQuery’s document.ready(). Das Startup Skript lädt die Routen für die Applikation, initialisiert über einen Dispatcher den jeweiligen Controller und startet eine Methode, genauso geht es ja auch in Cake zu. In der Controller Methode werden dann die Events dieser Seite registriert und die für die Intialisierung der Seite notwendigen Model bzw. View Methoden direkt aufgerufen.

Die Konzepte Model, View, Controller in Javascript zu übertragen ist recht einfach. Zuerst einmal wird ein Request durch ein Event ausgelöst. D.h. der Controller startet die für das Event registrierte Funktion und je nachdem ob es sich z.b. um ein Ajax Request oder Business Logik handelt wird eine Model Funktion aufgerufen. View Methoden bestehen aus Effekten z.b. das Ein/Ausblenden von Elementen, CSS Modifikationen und dem Rendern von neuen Elementen.

Die Kommunikation zwischen Cake und Javascript läuft über JSON und es können von Cake gerenderte View-Elemente oder auch Objekte/Arrays übergeben werden.

Die Ordnerstruktur ist ähnlich aufgebaut, wie in Cake d.h. während der Entwicklung ist das Javascript immer schön dokumentiert und in verschiedenen Dateien. Bei einem Deploy kann man dann z.b. über den Dojo Compressor eine einzelne Datei generieren.

Zu guter letzt hab ich die vorhandene Test Suite von Cake aufgebohrt, um die Javascript Dateien mit der Testing Umgebung von jsUnit testen zu können.

Wir arbeiten jetzt hier bei Ormigo mit dieser Architektur. Da im Moment sehr viel zu tun ist, gibt es noch kein Release. Wer es aber nicht aushält und unbedingt sehen will wie das Ganze funktioniert schreibt einfach einen Kommentar oder ne Mail an mich.

Update: Kurzes Beispiel:

Startup Skript:

var routes = {
    '/profil/': 'Users/profile',
    '/kontakte/*/': 'Users/contact_page',
};

$(document).ready(function(){
    dispatcher = new Dispatcher(routes);

});

Controller:

/*
 * UsersController
 *
 */
UsersController = function () {
    views['Users'] = new UsersView();
    models['User'] = new User();

    /**
     * User Profile
     */
    this.profile = function(filter) {
        $('div.person div.container').tabs({on: 1});

        $('div.fragment dl dd', filter).hover(
                    function(){views.Users.showTeaser(this);},
                    function(){views.Users.hideTeaser(this);});

        $('div.fragment dd', filter).click(function(){
            views.Users.showAllInput(this);
            views.Users.showInput(this);
        });

    }

    /**
     * Contact page
     */
    this.contact_page = function(filter) {
        $('div.person div.container').tabs({on: 1});
    }

}

Falls ihr nun eine lange Liste erwartet, so muss ich euch leider enttäuschen, es gibt nämlich bis jetzt kaum deutschsprachige CakePHP Ressourcen :|

http://groups.google.com/group/cakephp-de: “Forum” mit momentan etwas mehr als 20 Mitgliedern.

http://wiki.cakephp.org/tutorials:litte_german_example: Ein Tutorial für Anfänger, bei dem hauptsächlich um das Benutzen von bake geht.

irc.freenode.org #cakephp: Streng genommen ist dies keine deutschsprachige Ressource, aber es tummeln sich dort meistens auch Leute, die deutsch sprechen.

http://de.wikipedia.org/wiki/CakePHP: Eintrag bei Wikipedia.

http://rikman.mtb-news.de/tag/cakephp: Mehrere Beispiele von Applikationen, die mit CakePHP entwickelt wurden.

Und schliesslich noch dieses Blog hier ;)

routes.php

$Route->connect('/beitrag/anlegen', array('controller'=>'posts', 'action'=>'add'));

posts_controller.php

function add() {
    if (!empty($this->data)) {
        ...
    }
}

Das ist also kein Problem. Jetzt möchte ich aber den neuen Beitrag in der Url nicht über seine ID referenzieren, sondern auch hier eine sprechende Url verwenden.

routes.php

$Route->connect('/beitrag/anzeigen/*', array('controller'=>'posts', 'action'=>'view'));

posts_controller.php

function view($url) {
    if ($post = $this->Post->findByUrl(urldecode($url))) {
        $this->set('data', $post);
    }
}

Falls man das ‘anzeigen’ in der Url weglassen möchte, dann müssen in der routes.php auf jeden Fall alle anderen statischen Urls vor der ‘beitrag/*’ Route stehen.

Jetzt wäre es natürlich schön wenn man neben dem Anlegen, die restlichen CRUD Funktionen auch sprechend verlinken könnte. D.h. man ruft das Editieren eines Beitrags nicht über /beitrag/editieren/nette-urls/ sondern per /beitrag/nette-urls/editieren/ (oder auch /kommentar/anlegen/nette-urls/ vs. /beitrag/nette-urls/kommentar/anlegen/) auf.

routes.php

$Route->connect('/beitrag/:post_url/editieren/', array('controller'=>'posts', 'action'=>'edit'));

posts_controller.php

function edit() {
    if ($post = $this->Post->findByUrl(urldecode($this->params['post_url']))) {
        $this->set('data', $post);
    }
}

Am besten nutzt man eine Komponente, die beim Anlegen eines Beitrags den Titel in eine valide Url konvertiert. Die Url muss natürlich auch eindeutig sein, ein UNIQUE auf das Datenbankfeld und eine entsprechende Prüfung in der Komponente sind also noch nötig. Das könnte dann z.B. so aussehen:

class UrlComponent extends Object {
    /**
     * lower case without special chars
     */
    function getNiceUrl($str, $except=array()) {
        $str = strtr($str,"ÀÁÂÃÄÅàáâãäåÇçÒÓÔÕÖØòóôõöøÈÉÊËèéêëÌÍÎÏìíîïÙÚÛÜùúûüÿÑñ",
        "AAAAAAaaaaaaCcOOOOOOooooooEEEEeeeeIIIIiiiiUUUUuuuuyNn");

        $str = strtolower(trim ($str) ) ;

        $str = preg_replace ('/[^a-z0-9\-\.,\*]/', '-', $str) ;
        $str = preg_replace ('/([\-\.,\*]{2,})/ue', "substr('\\1', 0, 1)", $str) ;
        $str = preg_replace ('/^[^a-z0-9]|[^a-z0-9]$/', '', $str ) ;

        $i = 1;
        while(in_array($str, $except)) {
            $str = $str . '-' . $i;
            $i++;
        }
        return $str;
    }
}

Nach dem das Konzept fertig war und die Applikationsstruktur in Datenbanktabellen (es sind nur fünf Stück) übersetzt wurde, konnte ich die Applikation von der ersten getippten Codezeile (irgendwann am Donnerstag, 22. Juni 2006) bis zum Release (Montag, 26. Juni 2006) in nur gut 20 Arbeitsstunden fertig stellen.

Auch die anderen Passagen sind sehr aufschlußreich. Einen Screenshot seiner CakePHP-Site hat er lobenswerter Weise auch schon in der Flickr-Gruppe veröffentlicht.