Welcome to The Cookbook

Eine Komponente ist eine Klasse, die uns bei der Controller-Logik unterstützt. Soll eine Programm-Logik von verschiedenen Controllern (oder Applikationen) gemeinsam benutzt werden, ist eine Komponente in der Regel die richtige Wahl. Als Beispiel sei die Core-Klasse EmailComponent erwähnt, mit der das Erstellen und Versenden von E-Mails ein Kinderspiel ist. Anstatt eine Methode die diese Aufgabe erfüllt in einem Controller zu implementieren, kann diese Logik gebündelt werden um sie gemeinsam benutzen zu können.

Controller verfügen des Weiteren über Callback-Routinen. Diese Callbacks sind für den Fall gedacht, daß Programmlogik zwischen CakePHP's internen Transaktionen eingefügt werden soll. Verfügbare Callbacks sind:

• beforeFilter(), wird vor jeglicher Controller-Aktion ausgeführt
• beforeRender(), wird nach der Controller-Logik, aber vor dem Rendern des Views ausgeführt
• afterFilter(), wird nach allen Controller-Aktionen einschließlich dem Rendern des Views ausgeführt. Zwischen afterRender() und afterFilter() gibt es keinen Unterschied, außer wenn die Funktion render() manuell in einer Controller-Methode aufgerufen wurde und anschließend noch Code ausgeführt wird.

A Helper is a class that aids in view logic. Much like a component used among controllers, helpers allow presentational logic to be accessed and shared between views. One of the core helpers, AjaxHelper, makes Ajax requests within views much easier.

Most applications have pieces of view code that are used repeatedly. CakePHP facilitates view code reuse with layouts and elements. By default, every view rendered by a controller is placed inside a layout. Elements are used when small snippets of content need to be reused in multiple views.

Similarly, Behaviors work as ways to add common functionality between models. For example, if you store user data in a tree structure, you can specify your User model as behaving like a tree, and gain free functionality for removing, adding, and shifting nodes in your underlying tree structure.

Models also are supported by another class called a DataSource. DataSources are an abstraction that enable models to manipulate different types of data consistently. While the main source of data in a CakePHP application is often a database, you might write additional DataSources that allow your models to represent RSS feeds, CSV files, LDAP entries, or iCal events. DataSources allow you to associate records from different sources: rather than being limited to SQL joins, DataSources allow you to tell your LDAP model that it is associated to many iCal events.

Just like controllers, models are featured with callbacks as well:

• beforeFind()
• afterFind()
• beforeValidate()
• beforeSave()
• afterSave()
• beforeDelete()
• afterDelete()

The names of these methods should be descriptive enough to let you know what they do. Be sure to get the details in the models chapter.

Both controllers, helpers and models have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.

Although they aren’t a class or file, routes play a role in requests made to CakePHP. Route definitions tell CakePHP how to map URLs to controller actions. The default behavior assumes that the URL “/controller/action/var1/var2” maps to Controller::action($var1, $var2), but you can use routes to customize URLs and how they are interpreted by your application.

Some features in an application merit packaging as a whole. A plugin is a package of models, controllers and views that accomplish a specific purpose that can span multiple applications. A user management system or a simplified blog might be good fits for CakePHP plugins.