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.

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.

echo $html->link(
	$html->image('cake.power.gif', array('alt'=> __("CakePHP...", true), 'border'=>"0")),
	'http://www.cakephp.org/',
	array('target'=>'_blank'), null, false
);

This displays the small “CakePHP Power” badge with a link to their website. Much code for just a image surrounded with a link, eh?

The $html->image() method has a option called ‘url’ that automatically does this for you. Only limitation is that you can’t pass attributes to the link tag. But who really needs “target=_blank” in XHTML world anyway?

So here’s the same thing, only without the clutter:

echo $html->image('cake.power.gif', array('url' => 'http://www.cakephp.org', 'alt' => __('CakePHP...', true), 'border' => 0));

Tada! There you have it. Of course ‘url’ accepts arrays and everything else since it passes the value straight into Helper::url();

Enjoy

Sometimes we have more than one model that uses slugs. For example: Tags, Posts, Categories. That’s why i add the following to AppModel which allows me to call it on any model.

function slugify($text) {
	return low(Inflector::slug($text, '-'));
}

But because i am lazy i just use one of the model callbacks to automate the “slugification(tm)”.

function beforeSave() {
	if ($this->hasField('slug') && isset($this->data[$this->alias][$this->displayField])) {
		$this->data[$this->alias]['slug'] = $this->slugify($this->data[$this->alias][$this->displayField]);
	}
}

So on any model that has a “slug” field in the associated table we always slugify the displayField (usually “name”) and keep it fresh. Dead simple.

First of all: It’s a pain in the ass – Secondly: It’s a breeze when it’s done.

Some beginners, just like me, may have wondered about why your generated schema does not reflect the exact layout after doing “migrate up” with the exact same file. For now i will get at the integers, because i think they are quiet important to know and i at least couldn’t find anything about it.

You can basicly set any integer type using YAML, but you need to know what length will be translated to what. Here is a small chart explaining just that.

• length: 1 => tinyint(4)
• length: 2 => smallint(6)
• length: 3 => mediumint(9)
• length: 4 => integer(11)

Everything greater than 4 will become bigint(20). If we look at length as a setting for the sub-fieldtype rather than being the real length of the field, this all makes sense. Dont bother trying to set length to 11 .. it wont help.