The $base property tells you the current directory of the application (roughly put). If you application runs in http://example/app/ the $base property has the value /app.

The $here property tells you the current directory + the current action path. If you request http://example/app/admin/users/home the $here property has the value /app/admin/users/home.

We can use this info to our advantage when writing Ajax request in our external Javascript files. What i always do is using the JavascriptHelper to generate a code block with exactly these two values.

$javascript->codeBlock("var base = '{$this->base}, here = '{$this->here}';'");

I usually throw that line in my layout before i add anythings else, so that this info is available in all my scripts.

Now whenever i want to call something with Ajax i can either use Ajax.Request(base + '/controller/action.json'); or simply Ajax.Request(here + '.json'). If i ever decide to move the application i no longer need to worry about the base path.

Same goes for our webroot folder of course: $imgFolder = base + '/img/';

Another practice i found useful is when you want to submit a CakePHP form with Ajax. Instead of figuring out what path you need to POST to, just query the action attribute of the form. Much easier than writing the url yourself, even easier than using base.

// ajax post on all forms, just for demo
$$('form').invoke('observe', 'submit', function(evt){

  var form = evt.element();
  new Ajax.Request(form.readAttribute('action') + '.json', {
    parameters: form.serialize(),
    onComplete: function(xhr) {
      // added .json for fun
      // maybe do something neat with validationErrors
    }
  });

});

This should help you keeping your Javascript codebase lean.

Let’s stick with the admin panel example:

$this->layout = 'admin';

Now we all do some neat Ajax or XML here and there sometimes, and for Ajax we probably end up delivering JSON from the very same actions (”Yes, CakePHP is smart like that”). For that you usually start by adding Router::parseExtensions('json') to the routes.php file.

This works fine as long as you don’t call the action for JSON while it is using a different $layout. If we, for example, call /admin/users/index.json, CakePHP will tell us that it is missing the layout view file: APP/views/layouts/json/admin.ctp. Meh!

I am not saying that this is bad. It is actually quiet useful in some scenarios, but in general most people will be happy sharing the same old APP/views/layouts/json/default.ctp with all parts of the application. So… how to fix this?

Add the RequestHandler component to your app and add the following code to your AppController::beforeFilter() method (create the method if needed):

if ($this->RequestHandler->isAjax() && $this->RequestHandler->prefers('json')) {
 	$this->layout = 'default';
}

Now everytime the browser (client) prefers “json” the layout is switched back to “default”. Simple as that.

You can extend the checks to other formats.

if ($this->RequestHandler->isAjax() || $this->RequestHandler->isRss() || $this->RequestHandler->isXml()) {
 	$this->layout = 'default';
}

Hope this helps

Here’s a quick workaround to that, using two calls to render() in a single action (comments welcome):

public function export() {
  $data = $this->{$this->modelClass}->find('all');
  $this->set(compact('data'));
  $rendered = $this->render();
  $fileext = 'xml'; // optional: $this->params['url']['ext'];
  $filepath = TMP.'rendered'.DS;
  $filename = md5(String::uuid()).'.'.$fileext;
  file_put_contents($filepath.$filename, $rendered); // php5 func
  $this->view = 'Media';
  $params = array(
    'id' => $filename,
    'path' => $filepath,
    'extension' => $fileext,
    'download' => true, // force download
    'name' => low($this->name).'-export' // fancy name
  );
  $this->set($params);
  $this->render(); // init download
}

That’s it. First you render the .ctp using all the fancy helpers, temporarly save the result on your (ram)disk, change the view to Media, reuse almost same variables for the params array and simply call render again. Since we change $this->view in between renders, we can use both view renderer in a row.

DRY: For the extension you could grab the current extension from $this->params['url']['ext'] if you used array('ext' => '...') in the HtmlHelper::link() url param. This makes the action even more generic.

For example: You have one “development” environment but you have multiple domains pointing to it and the app needs to behave differently based on that (language preset based on domain extension, vanity urls for user profiles, .. that kind of stuff).

There are of course alot of other reasons why that’s a good a idea. In general to avoid duplicate code and conflicts. To get around all that i needed support for arrays.

One approach to support arrays would be to just add it to the _match($param, $value) method in the Environment class, but it may not have been appropiate in all occassions. So i just followed Rafael’s lead and simply added support for instance methods. Since we may have our own class for environment config/param mapping (just create app_environment.php in /config/), it’s a good place to also add some helper methods.

That was the previous code (around line 90).

if (function_exists($param)) {
	$match = call_user_func($param, $value);
} else {
	$match = (env($param) === $value);
}
if (!$match) {
	return false;
}

I just added another “if-condition” and used getInstance to get the object.

$instance = self::getInstance();
if (method_exists($instance, low($param))) {
	$match = call_user_method(low($param), $instance, $value);
} elseif (function_exists($param)) {
	$match = call_user_func($param, $value);
} else {
// ... as above

Note the “low($param)“. I’ve set the value of $param to lower-case because param would be HTTP_HOST which doesn’t makes up for a good method name. Maybe could have used Inflector to make it camelcase just to enforce conventions here – but that would be overkill. ;-)

Okay.. so what happens here and how can we use that?

1. The getInstance method returns the AppEnvironment object, if present. So it’s imperative to have it, because we don’t want to mess with the original class.
2. method_exists looks in AppEnvironment for a lower-case method name of whatever is in $param. In our case this results to “http_host”.
3. If found, it calls the method on the $instance and returns the result. The result should be boolean.

I’ve edited my app_environment.php and added the following method:

/**
 * Support Arrays in HTTP_HOST param matching
 *
 * @param mixed $value string or array of hostnames
 * @return boolean
 */
public function http_host($value) {
	if (is_array($value)) {
		foreach ($value as $host) {
			if (env('HTTP_HOST') == $host) {
				return true;
			}
		}
	} else {
		if (env('HTTP_HOST') == $value) {
			return true;
		}
	}
	return false;
}

Should be pretty self explaining. Default to false. If $value is an array, walk through it and return true on the first match. If it’s not an array just check if $value matches the current HTTP_HOST.

With that in place i can now tweak my ’server’ config in the environment setup.

App::import('Vendor', 'Environment');

Environment::configure('development',
	array(
		'server' => array('localhost', 'testapp-local.com') // there we go!
	),
	array(
		'debug' => Configure::read('Env.development.debug'),
		'security' => Configure::read('Env.development.security')
	)
);
Environment::start();

That’s it. From now on we have the “development” environment running if the current HTTP_HOST is either “localhost” or “testapp-local.com”.

Edit: Oh.. btw. This is not just about http_host. You can of course add helper methods for any other param.

It involves a bit of hacking, but not much.

Edit Info.plist

First you need to tell the Plugin about the custom file-types. For that you need to view the package contents of QLColorCode.qlgenerator file.

It should be in /Library/QuickLook or in your home directory ~/Library/QuickLook.

Open the “Contents” folder and open the Info.plist file. Any decent texteditor will do. Now scroll down to line 270 or so. There you will find the UTTypeConformsTo sections.

I just copied the “css” block (from <dict> to </dict>) and placed it right under it.

- Change the UTTypeDescription to “PHP File”.
- Change the UTTypeIdentifier to “public.php”.

Then theres a dict-subsection with public.filename-extension as key.
If you followed my steps it should contain “css” (if so, replace “css” with “php”).

- Duplicate the <string> part a couple times and add “ctp” and “thtml” to the array.

The complete section should then look like this:

<dict>
	<key>UTTypeConformsTo</key>
	<array>
		<string>public.source-code</string>
	</array>
	<key>UTTypeDescription</key>
	<string>PHP File</string>
	<key>UTTypeIdentifier</key>
	<string>public.php</string>
	<key>UTTypeTagSpecification</key>
	<dict>
		<key>public.filename-extension</key>
		<array>
			<string>php</string>
			<string>ctp</string>
			<string>thtml</string>
		</array>
	</dict>
</dict>

Save and close the file. Your QuickLook plugin now recognizes ctp and thtml files. That’s great, but you need to do one more thing to actually get PHP syntax coloring.

Edit colorize.sh

Back in your Finder with the “package contents” navigate into the “Resources” folder and open the contained “colorize.sh”. That’s a shellscript which does a bit of evaluation before it actually calls the highlight program.

Around line 36 you’ll find something like a switch-block. Here it’s called “case”… Anyway. You might recognize the schema here and see that each “case” corresponds to a file extension. This is where we jump in and add our .ctp and .thtml sections.

Note that there is no “break” statement like in PHP. Each case ends with a double semicolon instead.

    *.ctp )
        lang=php
        ;;
    *.thtml )
        lang=php
        ;;

You can put these somewhere in the middle. As said, watch out for the semicolons. Save and close the file. Since you’ve modified the Info.plist in the first step you might have to let your system know about the changes. Execute the following two commands on your Terminal/shell to refresh the QuickLook service.

qlmanage -r
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f -v /Library/QuickLook/QLColorCode.qlmanager

Make sure it’s pointing to the correct plugin path (at the end of the long command..).
After refreshing QL it should work right away. Go to your “views” folder and try it out.

Enjoy!

I thought it’s cool to disable a field simply by using the disabled Element property. Being distracted by other parts in the app i just applied it and left it alone – “How can this be bad, right?”. After some more time i did test the form again and found myself being blackholed all of a sudden – whaaa? – Took me some time to find out what the problem was (grrr).

Here’s the reason

If you disable a field using Javascript, the field name and its value never reaches the server. This of course invalidates the Security Token and thus leads to a blackhole.

I must admit that this was kinda stupid but that’s how things can go after some hours in CakePHP-land. :-)

Some “validation scripts” also apply disable. So look out for that too. Just don’t mess around with the fields (..much), and avoid prefilled values using array('value' => 'bla') if plan to change the value with Javascript. A good workaround to that is to set the “initial value” on page load using Javascript. SecurityComponent and Ajax then shouldn’t be a problem at all.

It’s currently under heavy development, yet ready to use. I don’t think the interface will change much from here on out. The installation is similar to the DebugKit. Put the “eventful” plugin into your plugins folder and add the Behavior or Component to your app. This will include all dependencies and the system is ready to use.

Only one thing is different from regular plugins. There is a seperate “events” folder which is a empty layout for the system and the place for your event listener classes.

The System is also plugin aware. If you want to enrich your base application with event handlers from plugins just copy the “events” folder layout into the plugin directory and prefix the class filenames with the plugin name. (just like app_controller).

# /app/plugins/pizza/events/controller/pizza_users_controller_events.php
class PizzaUsersControllerEvents extends AppControllerEvents ...

I’ve created a (messy) README which goes on about how to use it. Basicly the workflow is: a) add the component/behavior, b) use the dispatch/dispatchEvent method in your actions/methods, c) create or modify the event listener class and add a matching “on” method. d) go nuts.

class UsersController extends AppController {
   var $components = array('Eventful.Event');
}

class UsersController extends AppController {
   var $components = array('Eventful.Event');
   function logout() {
      $this->Event->dispatch('UserLogout', array(
           'auth' => $this->Auth->user()
      ));
   }
}

File: /app/events/controller/users_controller_events.php

class UsersControllerEvents extends AppControllerEvents {
   function onUserLogout() {
      $this->log('User logged out...')
   }
}

Unlike the original implementation the plugin triggers all handlers of the same name. So if you have a “userLogout” event fired from your UsersController::logout() action the dispatchEvent method will trigger all possible candidates. Regardless in which listener class the method is.

class MembersControllerEvents extends AppControllerEvents {
   function onUserLogout($event) {
      if ($event->auth['isMember'])
          $this->log('Member logged out...')
   }
}

Enjoy. You can find it on github:

http://github.com/m3nt0r/eventful-cakephp

Let’s say you have unkown entities in your project – totally dynamic. Let it be a plugin, another model, not associated at all. Getting new functionality into an existing app can be a pain.

Events do help alot in this case, depending on how you layed out the triggers. Events notify all possible candidates (”can u handle?”) every time something interesting is happening, like “user logged in”, “new image was uploaded”, “post has been edited by xyz”, and so forth.

In this post i want to explain more about the benefits and how events could make your life alot easier in the long run.

Some example

Think of a users dashboard: A dashboard usually has alot of links to various aspects of the application, often categorized in blocks. You have a block for the user account itself, a block for the latest comments, a block to upload a new image, etc..

Now maybe user XYZ has access to post blogs, but maybe not. And maybe there is no blogging function at all. We could now bake our blogging MVC and write it into the dashboard action. No problem, right? But the more you add, you more have to maintain and watch out for. I know many projects with complicated group setups and stuff so this isn’t always that simple.

This is where Events come in handy. Let’s scratch the above and think our dashboard action is empty and there’s a single call to the EventDispatcher (the thing i use). If we now simply fire a “dashboardView” event any part of the codebase that can handle this event will perform its designated task independently.

function dashboard() {
    $data = $this->Events->dispatch('dashboardView', array(
        'user_id' => $this->Auth->user('id')
    ));
    $this->set('data', $data);
}

This allows the blog-facility (for example) to run code and add data to the dashboard() action, so that the action itself remains clean.

Normally you would load up some settings array with true/false, or you would just add a if/else in the dashboard() action.

function dashboard() {
   if ($mayAuthorBlog) ..
   if ($mayPostNews) ..
   if ($justRegistered) ..
   ...
}

All this is not necessary when using events, since events usually don’t care if they are handled. They are just fired and poke around and execute whatever responds.

With “poking-around” i mean that you may have multiple handlers for a single event. So the Post, Image, Blog, Friend MVC .. all of them can respond to the current action. Even if they are out of scope.

The other way around

If we decide to drop any functionality later on, we just delete the event-listener, or delete the method that usually would respond. A common task may be: “The blogging dashboard item should not be intergrated into the dashboard anymore”. Remove the listener from your Blog-MVC and you’re done. Not touching the working dashboard() action at all.

See, if we wrote this without Events the removal of this functionality would require that we delete the if/else (or what have you) from the dashboard() action, which is destructive and eventually leads to bugs and headaches. Removal of event-listeners don’t harm your app.

…for the non believers

One can argue: “Why not simply add a private method for that?”

Well.. the keyword is “unkown”. Events enrich a function by providing an open interface to hook up to (so to speak). If you wrote something new you just provide the listener for your current/core app and be done with it.

class UserControllerEvents extends AppControllerEvents {
   var $name = 'UserController';
   function onDashboardView($event) {
       $event->Controller->User->logVisit($event->user_id);
   }
}

class BlogControllerEvents extends AppControllerEvents {
   var $name = 'BlogController';
   function onDashboardView($event) {
       return $event->Controller->Blog->getMostRecent();
   }
}

Private Methods or “helping” methods are bound to the main codebase and scope and as such quickly become obsolete or hard to manage. It’s also not so easy to call other parts of your cake app “just like that”. The system described works as one huge layer and has access to everything.

What do you think?

Let me know in the comments.

Always add a “empty” entry to the result

function find($conditions = null, $fields = array(), $order = null, $recursive = null) {
	if (is_array($conditions)) {
		return parent::find($conditions, $fields, $order, $recursive); // old interface
	} else {
		switch ($conditions) {
			case 'list':
				$result = parent::find($conditions, $fields, $order, $recursive);
				$return = $result; // default

				if (!empty($result)) {
					$return = aa('', __("-- please select --", true));
					foreach ($result as $id => $name)
						$return[$id] = $name;
				}

				return $return;
			break;

			default:
				return parent::find($conditions, $fields, $order, $recursive);
			break;
		}
	}
}

Okay, that works and i don’t have to add ‘empty’ everywhere. I modified the method a little further (not actually using it, but maybe someone likes it..) for you to grab. It will still require that you modify all files, but this way you have more control.

Adding “empty” to the find() options array

function find($conditions = null, $fields = array(), $order = null, $recursive = null) {

	if (is_array($conditions)) {
		return parent::find($conditions, $fields, $order, $recursive); // old interface
	} else {
		switch ($conditions) {
			case 'list':
				$result = parent::find($conditions, $fields, $order, $recursive);
				$return = $result; // default

				if (!empty($result) && isset($fields['empty']) && $fields['empty'] != false) {
					$return = aa('', $fields['empty']); // begin with whatever is in 'empty'
					foreach ($result as $id => $name)
						$return[$id] = $name;
				}

				return $return;
			break;

			default:
				return parent::find($conditions, $fields, $order, $recursive);
			break;
		}
	}
}

Everything above goes to app_model.php of course. With the last snippet you are able to move the “empty” option to the controller and go like this:

$categories = $this->Category->find('list', array('empty' => __("-- please select --", true)));

Enjoy & Happy Easter!

$this->User->find('first');
pr ($this->User->record); // has the full record

$this->User->record->username = 'BlaBlubb';
$this->User->record->email = 'bla@blubb.com';
$this->User->save(); // saves full record 

$this->User->find('first');
pr ($this->User->record); // jup, that worked.

Useful? hmm.. maybe. It was fun to explore though. If you are interested in the Behavior, i’ve put it into a gist.