Ich verwende die Version 1.2. Aktuell in zwei Varianten mit dem RC2 und einem einigermassen aktuellem NightlyBuild. Ich gehe davon aus, das ich noch eine Weile benötige um richtig drin zu sein und dann sollte ja ggf. schon ein RC3 oder eine Release in Aussicht stehen.
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.
Tags: app_model.php, beforeSave(), MVC, PHP/ PHP-Frameworks/ CakePHP
This entry was posted on Friday, September 5th, 2008 at 14:33 and is filed under PHP/ PHP-Frameworks/ CakePHP. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.
September 9th, 2008 at 20:28
Auch ein schönes PHP-Framework: http://www.symfony-project.org/ vor allem vorbildlich Dokumentiert.
September 9th, 2008 at 23:37
Hi Werner,
ich habe mich aus verschiedenen Gründen gegen symfony als “Einstiegstest” entschieden. Mit am Besten bringt es dieser Blogeintrag rüber: http://blog.t8d.de/2007/07/02/php-framework-vergleich-cakephp-vs-symfony/
Sehr warscheinlich werde ich aber auch nochmal mit symfony arbeiten – sollte mir cake zu “eng” werden.
ciao
Klaus
September 11th, 2008 at 15:25
Hi Klaus,
ja an den Pros/Contras ist schon was dran. Ich kämpfe, wenn ich Zeit habe, gerade mit Symfony. Dazu habe ich mir das vor kurzem erschienene Buch “Das Symfony Framework: Enterprise Anwendungen mit PHP” gekauft. Leider ist das Buch geschrieben worden, als Symfony gerade den Sprung von Version 1.0 auf 1.1 gemacht hat. Dadurch haben sich durchgehend kleinere Fehler im Buch eingeschlichen, die gerade bei der Einarbeitung etwas hinderlich sind und das ganze sagen wir “verkomplizieren”. Naja, halt uns und die Welt auf dem aktuellen Stand, wie deine CakePHP-Evaluierung so voran schreitet.
Ciao,
Werner