Blog :: deam.org » PHP/ PHP-Frameworks/ CakePHP

Core Helpers: HTML

Klaus M. Brantl — Fri, 31 Oct 2008 09:17:34 +0000

Ich habe zwar in den letzten Tagen sehr viele graue Haare auf Grund von HABTM bekommen, aber das ist ein Thema für einen separaten Post. Heute gibt es wieder eine undokumentierte Kleinigkeit: TD-Optionen bei tableCells.

In der aktuellen Doku steht lediglich der Teil mit den TR-Optionen drin. Das man aber auch TD’s mit zusätzlichen Angaben versehen kann, steht da leider nicht drin. Erst durch das Ticket https://trac.cakephp.org/ticket/2406 hab ich herausgefunden das es diese (lebens-)notwendige Funktion gibt :-)

Ist eigentlich ganz einfach – das bisherige Beispiel:

tableCells(array(
array('Jul 7th, 2007', 'Best Brownies', 'Yes'),
array('Jun 21st, 2007', 'Smart Cookies', 'Yes'),
array('Aug 1st, 2006', 'Anti-Java Cake', 'No'),
));
?>

//Output
Jul 7th, 2007Best BrowniesYes
Jun 21st, 2007Smart CookiesYes
Aug 1st, 2006Anti-Java CakeNo

Und das ist meine kleine Ergänzung für die CakePHP-Doku:

tableCells(array(
array('Jul 7th, 2007', array('Best Brownies', array('style'=>'font-weight:bold;')) , 'Yes'),
array('Jun 21st, 2007', 'Smart Cookies', 'Yes'),
array('Aug 1st, 2006', 'Anti-Java Cake', array('No', array('style'=>'background-color:#ff0000;'))),
));
?>

//Output
Jul 7th, 2007Best BrowniesYes
Jun 21st, 2007Smart CookiesYes
Aug 1st, 2006Anti-Java CakeNo

Es gibt noch einen count-Parameter, den ich mir aber noch nicht näher angesehen habe.
Das man ’s also auch direkt mit Attributen versehen kann, macht die ganze Sache dann doch recht elegant.

codeBlock und object: JSON mit CakePHP

Klaus M. Brantl — Wed, 15 Oct 2008 15:56:23 +0000

Mit $javascript->codeBlock lässt sich recht elegant Javascript-Code einbetten (vor allem interessant, wenn man die ein oder andere Referenzinformation für eine JS-Funktion zur Verfügung stellen will – und das ohne AJAX).

$javascript->codeBlock(“alert(‘hallo’);”, array(‘inline’ => false));

Das ‘inline’ => false ist Gold wert. Hat man in seinem default.ctp schön brav in den geschrieben, dann wird der JS-Code nicht mitten in die Seite “geschmiert”, sondern schön in den -Bereich des Dokuments platziert. Sowas sorgt für Ordnung.

$javascript->object($this->viewVars['adressenstatus'], false, ‘adressenstatus = ‘, ‘;’);

Die object-Funktion macht aus einem Array entsprechend JSON – mit allem was dazugehört. In diesem Fall beziehe ich mich auf ein zweidimensionales Array, welches ich sowieso für die Ausgabe eines Popups brauche. Das $this->viewVars['adressenstatus'] wird mit einem Präfix ‘adressenstatus = ‘ und einem Suffix ‘;’ versehen. Und schon habe ich ein schönes Javascript-Objekt. Das sieht dann in etwa so aus:

adressenstatus = {"Mitgliedschaft":{"1":"Plus-Mitgliedschaft","2":"Standard-Mitgliedschaft","3":"Gruppen-Mitgliedschaft"},"sonstiges":{"0":"Neuanmeldung","4":"Interessent","5":"Multiplikator","6":"Referent","7":"ruhende Mitgliedschaft","8":"Presse\/ \u00d6ffentlichkeitsarbeit\n"}};

Jetzt kombiniere ich beides und schwups hängt das ganze im -Bereich meiner Seite:

$javascript->codeBlock($javascript->object($this->viewVars['adressenstatus'], false, 'adressenstatus = ', ';'), array('inline' => false));

Die Funktion $javascript->object werde ich wohl noch recht oft einsetzen. Vor allem auch in Zusammenhang mit AJAX.

Ziel der Übung von oben ist es bei einem onchange-Event eines Popups entsprechende Formularteile ein- oder auszublenden. Hier macht es imho wenig Sinn mit einem XHTTP-Request zu arbeiten, wenn der Datenumfang des Popups klein ist (in diesem Fall ja nur 9 Datensätze). Da liefert man das Objekt für Javascript einmal im und bezieht sich dann entsprechend darauf.

MVC: ein schöner Gedanke

Klaus M. Brantl — Fri, 05 Sep 2008 12:33:30 +0000

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.

CakePHP: mal was anderes lernen

Klaus M. Brantl — Thu, 04 Sep 2008 19:30:17 +0000

Das deam.org-Blog wird mit Arbeit eröffnet.

Ich habe über die letzten Jahre ein recht brauchbares framework entwickelt. Ein kleines framework, das den jeweiligen Nutzungsumständen immer gut anzupassen war. Inzwischen ist das Entwickeln aber deutlich komplexer geworden, d.h. es müssen mehrere Leute gleichzeitig arbeiten können. Dabei hat mein framework ein paar Limitierungen – nicht zuletzt in der Dokumentation. Es bedeutet doch relativ hohen Aufwand Dritte einzuführen, mit denen man zum ersten Mal zusammen arbeitet.

Aus diesem Grund habe ich mich entschieden einen neuen Weg zu gehen, oder ihn zumindest zu suchen. Mitte August 2008 hatte ich endlich ein paar Stunden Zeit mit CakePHP zu beginnen. Von allen MVC-ausgerichteten frameworks erscheint mit CakePHP bislang als das am besten “verfügbare” (dazu später noch mehr). Allerdigs bin ich mir zum jetzigen Stand noch nicht sicher, wie viel effektiver ich damit arbeiten kann.

Über die nächsten Wochen bis voraussichtlich Mitte November werde ich versuchen mich in CakePHP einzuarbeiten und mir entsprechendes Handwerkszeug zurecht zu legen. Einen guten Teil davon werde ich in diesem Blog veröffentlichen – in deutsch.

Es gibt eine Menge Quellen, aber im deutschsprachigen Raum ist es etwas mager. Ausserdemist das Thema der richtigen Vorgehensweise (“hänge ich das jetzt ins Model oder mach ich ein Behavior draus?”) auch in der englischen Google-Group nicht immer hinreichend gut zu klären.

Meine Aufgabenstellung ist eine Adressverwaltung, die ich vor mehr als 10 Jahren in PHP geschrieben habe und die immer noch im Einsatz ist. Beim letzten Switch von PHP4 auf PHP5 hat sich bei dieser Verwaltung gezeigt, dass es doch ein kleinwenig zuviel Anpassungen bedingte. Das Projekt ist aber überschaubar genug, um sich nicht an planungstechnischen Details aufhalten zu müssen, aber komplex genug um sich mit CakePHP intensiver beschäftigen zu müssen.