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.

Getter/Setter is inspired by the function that is included in Zend Studio for Eclipse and creates public getVariable and setVariable methods from the member variables you select.

Here’s a example class:

class SomeClass extends SomeOtherClass {

	public $name = 'SomeClass';

	protected $_my_integer = 0;

	protected $_my_boolean = false;

	protected $_my_constant = THIS_IS_MY_CONST;

	private $__someEmptyString = "";

	// this is a $test
	static public $prop;
}

You simply select a bunch of member variables (like those above) in your class and hit the command CTRL + SHIFT + S (i know, probably there are better ones) to insert the methods.

Example output with just public $name selected:

	/**
	 * Get value of $this->name
	 *
	 * @access public
	 * @return string
	 */
	public function getName() {
		return $this->name;
	}

	/**
	 * Set the value of $this->name
	 *
	 * @param string $value
	 * @access public
	 */
	public function setName($value) {
		$this->name = $value;
	}

There is some type detection in place for the PHPDoc tags aswell as recognition of static variables.

If i do the same command with protected $_my_integer:

	/**
	 * Get value of $this->_my_integer
	 *
	 * @access public
	 * @return integer
	 */

The return type is now “integer” as expected, since that’s the default value for this member variable.

For static variables the assignement is changed from $this to self:: and the methods also get a static flag in front of them.

	/**
	 * Get value of self::$prop
	 *
	 * @access public
	 * @return mixed
	 */
	static public function getProp() {
		return self::$prop;
	}

	/**
	 * Set the value of self::$prop
	 *
	 * @param mixed $value
	 * @access public
	 */
	static public function setProp($value) {
		self::$prop = $value;
	}

It works with single lines, aswell with multiple of course. Default values that are constants are always typed “mixed” as i find that definiton appropiate. Constants may contain string, bool, int.. so best guess is mixed. Also “null” is treated as “mixed” since it’s .. yeah.. null.

Of course there is some odd behavior which i couldn’t prevent but given the benefit you have these are acceptable.

Known Issues:

• Code is generated directly after the selected lines. Not at the end of the class or anywhere else fancy. This kinda sucks, but a quick copy paste after insertion will do.. There is no way for me to discover the code level (closing brace, etc.) and the Coda API doesn’t tell either.
• If you double click a member variable the semicolon is not selected (Coda issue/feature). Since the plugin outputs directly after what has been selected the semicolon is pushed down (after the generated methods). Prevent this by selecting the whole line, or include semicolon.

I think it’s cool anyhow and maybe i get a hang on it and publish some more plugins geared towards CakePHP.

I hope you enjoy this little helper plugin!


DownloadWith Coda installed the plugin should add and activate itself after you double click the package. If not, you can place it in ~/Library/Application Support/Coda/Plug-Ins/. To uninstall just delete the package and restart Coda. If you want to have another shortcut just create one using MacOSX Shortcut Menu in your System Preference Panel.

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!

Sprockets is a Ruby library that preprocesses and concatenates JavaScript source files. It takes any number of source files and preprocesses them line-by-line in order to build a single concatenation. – getsprockets.org

I wanted to port it to PHP or find clever ways to use it in CakePHP (shell?). But before you start something like this you should check if there isn’t already a project and so i found PHPSprockets from Stuart Loxton. PHP Sprocket is a port of Sprockets. Cool.. so the meat of sprockets is already available :)

PHP Sprockets currently acts as a transparent proxy as default and caches results. Because of this you do not have to initialize any classes in your app and sprocket stays separate.

Thanks to GitHub i just forked the project and began pimping Stuarts class.
Here are the major differences from the orignal port:

• The main class file has been renamed to “Sprocket”
• Commands are now classes. It is easy to extend Sprocket with new commands.
• Instead of YML this fork uses INI files for providing constants.
• Easy to extend due more abstraction, setters and a array based option interface
• Seperate render stage (with autoRender option to mimic the original render-on-construct).
• Also works with other files, like CSS and whatever you want to concat.. (see demo)
• Selective minification for JS and CSS out of the box. Just add “minify” (see demo files)
• Fully documented sourcecode

I also added a demo and there is more info about my rewrite in the repo readme.
Enjoy! – http://github.com/m3nt0r/php-sprockets

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.

#! /bin/sh
#
# An SSH_ASKPASS command for MacOS X
#
# Author: Joseph Mocker, Sun Microsystems
#
# To use this script:
#     setenv SSH_ASKPASS "macos-askpass"
#     setenv DISPLAY ":0"
#
TITLE=${MACOS_ASKPASS_TITLE:-"SSH"}

DIALOG="display dialog \"$@\" default answer \"\" with title \"$TITLE\""
DIALOG="$DIALOG with icon caution with hidden answer"

result=`osascript -e 'tell application "Finder"' -e "activate"  -e "$DIALOG" -e 'end tell'`

if [ "$result" = "" ]; then
    exit 1
else
    echo "$result" | sed -e 's/^text returned://' -e 's/, button returned:.*$//'
    exit 0
fi

That’s the original script found on Retep’s Open Source Blog. I’ve reposted the script here because it was poorly formatted (quotes) and there is one thing to change.

Save the above as ssh-askpass:

sudo vi /usr/libexec/ssh-askpass

Paste the script, save the file (needs sudo password), make it executable

sudo chmod +x /usr/libexec/ssh-askpass

The setenv didn’t work on my 10.5.0 install. So instead, i had to use “export”:

export SSH_ASKPASS="macos-askpass"
export DISPLAY=":0"

Now i pushed current branch in textmate and it worked right away. Great! :)

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!