Nach dem Einlesen war mir klar, das ich mit dem 1.1 nicht mehr anfangen will, da hier einige grundlegende Teile fehlen. Zumindest so grundlegendes, dass ich nicht wirklich den Vorteil zu meinem framework gesehen habe. Das entscheidend neue (zumindest für mich) an 1.2 sind die eingebauten Validierungsregeln – das ist in der 1.1er deutlich “schlanker”.

Aber fangen wir doch mal von vorne an: MVC.

Ich bin ein Scripter. Ich schreibe schon eine gute Weile Perl- und fast genauso lange PHP-Scipts. ich denke von oben nach unten und habe mich eigentlich erst in den letzten 4 Jahren stärker auf Trennungen von Funktion und Inhalt konzentriert (vorher schon auch, aber eben nicht so intensiv).

Das MVC-Prinzip (Model-View-Controller) wird auf der CakePHP-Seite auch schön in deutsch beschrieben. Im Grunde ist es keine Hexerei. Es bedeutet aber viel Selbstbeherrschung. Der View-Teil ist dabei noch am leichtesten – nach dem Motto “hier nur Zeug zum Anzeigen rein und ausser ein paar IF-Abfragen keine wirkliche Logik machen”.

Model und Controller lassen sich dabei aber schon nicht mehr so gut trennen. Bzw. ist die Gefahr gross, dass man die Trennung nicht so klar macht. Ich habe inzwischen angefangen mich sehr auf die Callbackfunktionen zu konzentrieren. Diese stehen eigentlich immer jeweils nur in einem Typ zur Verfügung. Z.B. wenn ich beforeSave() verwende, dann ist das ein Model-Callback. Wenn ich also Daten kurz vorm Speichern (und in diesem Fall nach Validierung) noch “korrigieren” will, dann ist das der richtige Platz. Und da das beforeSave() nur in der Model-Klasse verfügbar ist, muss ich mch auch gar nicht aktiv zwischen Controller und Model entscheiden :-)

Was mir gestern erst so richtig klar geworden ist, dass man Superklassen hat. (WARNUNG: ich bin wie gesagt ein Scripter, deshalb kann es jetzt schonmal vorkommen, dass ich die Bezeichnungen nicht immer ganz korrekt hinbekomme). Das heisst man kann die Model-Klasse an oberster Stelle modifzieren. D.h. also ich kann mit app_model.php direkt im app-Ordner z.B. diese Funktion einsetzen:

class AppModel extends Model {
	function beforeSave()
	{
		/**
		 * Überprüft die Metadaten des Models und setzt dann die aktuellen Daten auf "null", wenn kein Inhalt gegeben ist.
		 *
		 * http://bakery.cakephp.org/articles/view/null-behavior
		 */

		$tableInfo = $this->schema();
		foreach ($tableInfo as $name => $field)
		{
			if($field['null'])
			{
				if(isset($this->data[$this->name][$name]) && $this->data[$this->name][$name] === '')
				{
					$this->data[$this->name][$name] = null;
				}
			}
		}

		return true;
	}
}

(Aus den Kommentaren der Bäckerei: http://bakery.cakephp.org/articles/view/null-behavior)

Das nenne ich Handwerkszeug. Solche Funktionen sind nicht Bestandteil von CakePHP – auch nicht als Konfigurationsoptionen. Es ist aber nicht besonders schwer sowas zu integrieren. Und genau daran arbeite ich gerade, da ich möglichst viel Funktionsweisen in eine Form bringen möchte, damit ich sie wiederverwenden kann. Da würde dann wohl auch der vendor-Ordner mit hereinspielen. Aber soweit bin ich noch nicht :-)
Ich arbeite mit einer MySQL und diese unterscheidet sehr wohl zwischen einem leeren String oder eben NULL. Und gerade bei formalen Feldtypen wie “date” ist es entscheidend ein NULL setzen zu können, wenn z.B. ein Geburtsdatum in der Adressverwaltung optional ist.

Aktuell integriere ich dieses Beispiel http://bakery.cakephp.org/articles/view/using-the-unobtrusive-date-picker-widget-in-cakephp für eine Datumsauswahl in der app_model.php – und zwar in einer Form das ich mich damit nicht mehr weiter befassen muss und in der entsprechenden View nur noch entscheiden muss “will ich oder will ich nicht”. Der Standardselektor für Datumsauswahl gefällt mir nämlich ganz und gar nicht.