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.

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