Kommentare zu Cake Bakery

Kommentare von Daniel Hofstetter zu Ausblick auf Cake3

Daniel Hofstetter — Thu, 23 Jul 2009 05:07:33 +0000

Ich denke, schlussendlich wird es auf einen (teilweisen?) Rewrite hinauslaufen. Aber zuerst dürfte wohl cake2 noch aktuell werden für NoseRub.

Kommentare von Daniel Hofstetter zu Warum man query() und execute() niemals nutzen sollte

Daniel Hofstetter — Tue, 07 Jul 2009 14:44:44 +0000

Ja, das ist das Risiko, wenn du query() und Callback-Methoden verwendest (wobei ich persönlich sehr selten die Callback-Methoden verwende). Auf der anderen Seite kann es auch sein, dass du plötzlich ein SQL-Statement ausführen musst, welches du nicht mit find() abbilden kannst, und dann hast du ebenso ein Problem…

Kommentare von How to use Themes in CakePHP by Cake Bakery zu Themes in CakePHP

How to use Themes in CakePHP by Cake Bakery — Tue, 07 Jul 2009 12:49:27 +0000

[...] In the comments to the german version of this article, Robert gives some advice on how to use view caching together with [...]

Kommentare von Robert Scherer zu Themes in CakePHP

Robert Scherer — Tue, 07 Jul 2009 12:10:54 +0000

Kleine Anmerkung: der zweite Nachteil vom Theming in CakePHP ist, dass es momentan nicht kompatibel zum Caching in PHP ist. Dieses greift nämlich schon im Dispatcher, bevor die Controller instanziiert werden.

Die erträglichste Möglichkeit, das trotzdem zu erreichen, ist es, eine Dispatcher-Klasse zu erstellen, die vom Dispatcher ableitet und dort die Methode cached() zu überschreiben. Voraussetzung ist natürlich, dass man schon vor dem Dispatchen der Controller-Action weiß, welches Theme verwendet werden soll.

Wenn man auch Element-Caching verwenden will, muss noch eine eigene View-Klasse erstellt werden, die von Theme ableitet und dort die Methode renderElement() bzw. element() überschreibt.

Kommentare von Timo Derstappen zu Warum man query() und execute() niemals nutzen sollte

Timo Derstappen — Mon, 06 Jul 2009 14:24:29 +0000

Hey Dirk, schön dass du den Blog wieder belebt hast! Und noch schöner, dass query aus deinem Cake Wortschatz verschwindet :)

Mit query zerstört man auch so gut wie alle Behaviors …

Kommentare von dirk.olbertz zu Warum man query() und execute() niemals nutzen sollte

dirk.olbertz — Mon, 06 Jul 2009 12:31:52 +0000

Was aber, wenn Du im beforeFind() die Abfrage selbst beeinflusst. Zum Beispiel weil Du ein Flag “deleted” in der Datenbank hast und dies im beforeFind() abhängig von den Rechten des Users setzt?

Wenn Du diese Funktionalität erst einbaust, nachdem Du Deinen query()-Aufruf bereits gemacht hast, kannst Du unerwünschte Effekte erhalten.

Wenn Deine Abfrage aber nur durch find() realisiert wird, hast Du das Problem nicht mehr.

(Ich weiß, dass ich in NoseRub auch noch query() benutze, will das aber so schnell wie möglich loswerden, wenn ich erst einmal die HABTM-Beziehung dort vernünftig gelöst habe…)

Kommentare von Daniel Hofstetter zu Warum man query() und execute() niemals nutzen sollte

Daniel Hofstetter — Mon, 06 Jul 2009 11:46:30 +0000

Nun ja, so pauschal würde ich das nicht sagen. Gerade bei komplexeren SQL-Abfragen ist es vielfach einfacher und verständlicher, direkt SQL (mit query()) zu verwenden. Und wenn du dies in einer Methode in deinem Model kapselst, dann rufst du einfach die Methoden auf, die sonst aus beforeFind()/afterFind() aufgerufen würden.

Kommentare von findCount() und belongsTo « Cake Bakery zu Fallstricke bei den Model-Relationen

findCount() und belongsTo « Cake Bakery — Mon, 06 Jul 2009 09:04:33 +0000

[...] Cake Bakery Rezepte für die Entwicklung mit CakePHP « Fallstricke bei den Model-Relationen [...]

Kommentare von Ridcully zu Framework vs. Bibliothek

Ridcully — Wed, 18 Mar 2009 18:55:03 +0000

Das ZendFramework ist nicht nur eine lose Sammlung von Klassen, sondern setzt auch das MVC Konzept um. Projekte in 20 Stunden sind auch mit dem Zend Framework hinzubekommen. Was ich sehr schön finde am Zend was auch den Cake oder einem anderen Framework zugute kommt ist das die Klassen auch einzeln zu verwenden sind, was bei bei anderen Framework nicht so einfach möglich ist.

Kommentare von Larry zu favicon.ico und die Nebenwirkungen

Larry — Mon, 04 Aug 2008 08:12:42 +0000

Der einzig richtige Weg, ist den Slash vor die URL zu setzen. /favicon.ico

Im Idealfall werden alle URLs von Links, Bildern oder sonstigen Verweisen immer vom Root aus, also mit Slash am Anfang gesetzt. So bleibt man flexibel und muss sich mit der obigen Problematik nie wieder beschäftigen.