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…

Wenn man aber, wie bei NoseRub Admins und Usern die Möglichkeit geben möchte, das Aussehen der gesamten Installation, oder aber der eigenen Profilseite anzupassen, sind die Themes eine prima Sache – und auch sehr leicht zu implementieren.

Die Templates für die Webseiten sind bei Cake in sogenannte Views organisiert und liegen im Normalfall unter /app/views. Zugehörige CSS- und JavaScript-Dateien befinden sich unter /app/webroot/.

Um die Unterstützung von Themes im eigenen CakePHP Projekt zu aktivieren, muss man erst einmal im entsprechenden Controller auf eine andere View-Klasse wechseln. Der Einfachheit halber kann man das direkt im AppController machen:

class AppController extends Controller {
    public $view = 'Theme';
    ...
}

Vor dem Rendern muss CakePHP nun außerdem mitgeteilt werden, welches Theme benutzt werden soll. Für NoseRub habe ich das ebenfalls im AppController gemacht um als Standardwert ein vorgegebenes Theme auszuwählen:

class AppController extends Controller {
    public $view = 'Theme';
    public $theme = 'default';
    ...
}

Man kann das aber natürlich auch an anderer Stelle im Controller ändern. Wenn also z.B. eine Profilseite des Users angezeigt werden soll und dabei ein vom User ausgewähltes Design genommen werden soll, kann man dies so erreichen:

class UsersController extends AppController {
    public $uses = array('User');

    public function view($username) {
        $user = $this->find('first', array(
            'conditions' => array(
                'User.username' => $username
            )
        ));
        $this->set('user', $user);

        // todo: check that user exists before proceeding!
        // todo: check that value of user theme is valid

        $this->theme = $user['User']['theme'];
    }
}

Die Daten für dieses View such CakePHP nun an folgenden Orten: /app/views/themed/[theme name]/ und /app/webroot/themed/[theme name]/. Für ein Theme mit dem Namen green würde Cake nun also zuerst das Default-Layout (ein anderes ist ja nicht gesetzt) unter /app/views/themed/green/layouts/default.ctp suchen und dann das View, welches hier gerendert werden soll in /app/views/themed/green/users/view.ctp.

Dabei ist das schöne, dass Cake immer auf die Version ohne themed im Pfad zurückgreift, falls die Variante mit themed gar nicht vorhanden ist. Wenn man seine Applikation also schön mit Views und Elementen strukturiert, können die Themes sehr einfach ausfallen und teilweise nur anderes CSS enthalten. (Man denke nur an CSS Zen Garden!)

Das funktioniert natürlich auch für Javascript Dateien. In NoseRub wird das JavaScript per Element in das Layout hinzugefügt und zwar über folgende zwei Zeilen:

echo $javascript->link('theme.js');
echo $javascript->link('noserub.js');


Unter /app/webroot/js/theme.js liegt nun eine leere Implementierung, die automatisch von einer themespezifischen theme.js überschrieben wird, weil CakePHP diese ja beim Rendern vorziehen wird.

Einziger wirklicher Nachteil der Themes in CakePHP ist, das Views und CSS/JS von einander getrennt sind. Man kann also nicht einfach nur ein einziges Verzeichnis irgendwo hochladen um ein Theme zu “installieren”, wie das z.B. bei Wordpress geht. Andererseits ist das aber auch ein riesiger Sicherheitsgewinn, weil der PHP-Code in den Views abseits des öffentlich zugänglichen Webroots (vorausgesetzt, der liegt auf /app/webroot/, wie es empfohlen wird).

Für NoseRub werden wir dafür aber im Admin-Bereich eine Upload-Möglichkeit geben, wo dann ein Archiv mit zwei Ordnern views und webroot erwartet werden – sofern uns keine bessere Möglichkeit einfällt…

Update: In den Kommentaren hat Robert noch eine wichtige Anmerkung zum Thema Caching und Themes gemacht.

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.

Deshalb sollte man auch vor einem findCount() auf expects() zurückgreifen, um nur die Models zu berücksichtigen, die auch gewollt sind:

$this->MeinModel->recursive = 0;
$this->MeinModel->expects('MeinModel');
$anzahl = $this->MeinModel->findCount();

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.

$mein_model->cacheQueries = false;
$mein_model->query('SELECT COUNT(DISTINCT plz) FROM test_table');

$mein_model->cacheQueries = false;
$mein_model->execute('SELECT COUNT(DISTINCT plz) FROM test_table');

query() beachtet nämlich die Cache-Einstellungen via cacheQueries nicht, während execute() dies aber tut. Die Rückgabe beider Methoden ist identisch, man sollte also nach Möglichkeit execute() statt query() benutzen, damit man mittels cacheQueries immer die Möglichkeit hat, auf das Model-Caching von Cake Einfluß nehmen zu können.

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.

Weiters wurde die offizielle Bakery von CakePHP eröffnet. Unter http://bakery.cakephp.org kann man Tutorials, Case Studies und Code Snippets finden. Geplant ist, dass sämtliche Inhalte vom Wiki und von den Code Pastes auf die Bakery übertragen werden. Das heißt, jeder ist dazu aufgefordert Beiträge zu schreiben.

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.