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.

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();

$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.

class AppModel extends Model
{
  function __construct($id=false, $table=null, $ds=null) {
    parent::__construct($id, $table, $ds);
    $this->execute( "SET NAMES 'UTF8'" );
  }
}

Auf GetTheAnswer gibt es von mir ein etwas ausführlicheres Tutorial zu Encoding jedoch in Englisch.

Die Lösungen für beide Fragen sind sehr einfach, doch sind sie zugegebenermassen nicht ganz offensichtlich für Anfänger. Am besten zeige ich die Lösungen gleich anhand von zwei einfachen Beispielen.

Zuerst der Controller, der kein Model verwendet:

class WithoutModelsController extends AppController
{
    var $uses = array();

    // some functions
}

Und hier das Model, welches keine Tabelle verwendet:

class ModelWithoutTable extends AppModel
{
    var $useTable = false;
}

Zwischenruf: Eigentlich sollte diese Funktion ja im Form-Helper angesiedelt, meint selbst Nate (dritter Abschnitt).

Im View wird der Helper so verwendet:

echo $html->dateTimeOptionTag('Booking/date_from', 'DMY', 'NONE', null, null, null, false);

Bitte nicht durch den Namen dateTimeOptionTag verwirren lassen, denn es lassen sich damit auch reine Datumsangaben realisieren! Dies wird dadurch erreicht, dass der dritte Parameter ($timeFormat) auf NONE gesetzt wird. Andere Optionen für diesen Parameter sind 12 und 24, womit dann ausgewählt wird, in welchem Format die Uhrzeit angezeigt wird.

Den letzten Parameter ($showEmpty) habe ich hier auf false gesetzt, damit der Benutzer nicht eine Angabe leer lassen kann, wie z.B. Jahr oder Monat.

Ansonsten ist die Verwendung ganz einfach. Das Feld date_from ist in der MySQL-Datenbank vom Typ DATE und wird bei der Ausgabe über den Helper automatisch auf drei Select-Boxen für Tag, Monat und Jahr aufgesplittet.

Um die Daten im Controller anschließend auch wieder in nur ein Feld von $this->data['Booking'] zu haben, muss noch

$this->cleanUpFields();

vor der weiteren Verwendung in der entsprechenden Action eingebaut werden. Diese Funktion sammelt nämlich die einzelnen Variablen, wie sie durch den Helper in den HTML-Code der Seite geschrieben wurden und setzt sie zur ursprünglichen Variable zusammen (hier date_from).

Aber Vorsicht! Im Moment gibt es noch einen Bug in cleanUpFields(). Dazu muss man verstehen, wie cleanUpFields() funktioniert: diese Controller-Funktion geht alle Felder des aktuellen Models durch und überprüft, ob dort eines mit DATE oder DATETIME vorhanden ist. Wenn ja, wird $this->data entsprechend modifiziert. Wenn man in seinem Controller nun aber auf mehrere Models zurückgreift, werden trotzdem immer nur die Felder des Models überprüft, welches zum aktuellen Controller “gehört”.

Bis der Fehler gefixt wird, kann man sich in seinem Controller so behelfen:

$this->modelClass = 'Bookings';
$this->cleanUpFields();
$this->modelClass = 'User';

In diesem Beispiel befinden wir uns im UsersController und wollen cleanUpFields() für das Model Bookings benutzen.