We are currently using the FBML method of publishing our wonderful Lord of the Rings licensed game. All has been rosey in the garden of The One Ring, until we found out that the FBJS Flash bridge is the most unimpressive piece of script I have ever seen. We found that random errors would creep into the loading of the SWF because of this bridge, and decided that the only way around it was to bite the bullet and move to iframe mode.

For those who don’t know, iframe mode basically means you can side-step all the ridiculous limitations imposed upon you by Facebook, and basically just have your application sit in an iframe, interacting with Facebook through the API and a set of Javascript client libraries. The wonderful thing is that we could keep our “invite your friends!” and other fbml based pages as fbml. Hooray!

However, what I didn’t recon on was the amazing lack of documentation and examples when it comes to working in iframe mode. The crux of any successful Facebook app lies in self-publication, encouraging the user to tell the world how he has gained a new level in growing tulips, or played his longest Scrabble word ever. We wanted to be able to do this from within the PHP (well HTML if your being a pedant), or within the SWF. Simples. You’d think so, but apparently not.

After wrestling the Javascript library to the ground, I came to the following conclusions:

1. The Facebook Javascript client library is woefully under-documented.
2. You need to use the FB.Connect functions, even though your application is not technically a Facebook Connect app.
3. You need to have an xd_receiver.htm file on your server in order to communicate with the JS API.
4. You need to configure the callback URL on the “Connect” tab of the developer settings for your app.
5. You can then use the following code to spawn a stream post box…

<CODE REMOVED, NOW OUT OF DATE! LEAVE A COMMENT IF NEW CODE WILL BE HANDY>

It’s a starting point at least, and as I’ve spend the last few days looking for just this example, I thought it might help someone down the line. This may not be the best way to achieve my goal, all comments would be received with thanks.

Also, you may well find FB.Connect.getStatus() handy, it was how I found out that my connect settings were wrong in the app settings page.

Useful Links:

• http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Channel
• http://wiki.developers.facebook.com/index.php/JavaScript_Client_Library
• http://developers.facebook.com/docs/?u=facebook.jslib.FB.Connect.streamPublish
• http://developers.facebook.com/docs/?u=facebook.jslib.FB.Connect.get_status

Basically, each ::addValidtor method takes 3 parametres, the type of validator, wether to break the chain on validation failiure,  and an array of custom options.  One of these options (messages) needs to be set in order for the form to display your custom messages. These messages take the form of a key=>value array where the key is they type of validation faliure (string of between 5 and 10 characters could be too short or too long), and the value is the custom error message.

For example:

->addValidator('stringLength', true, array('min'=>1, 'max'=>32, 'messages'=>array(Zend_Validate_StringLength::TOO_LONG =>'The maximum number of characters is %max%')))

This looks like a bit of a mess to me, so I decided to create an array of the messages arrays, and pass that to the options array instead.

One of the biggest changes to note, is that before I was using the custom messages, I was just passing the option parameters as values, and no in key=>value pairs. For example in the stringLength example above, my old code was:

->addValidator('stringLength', true, array(1,32))

In fact, once I got my head around having to pass the custom options as key=>value pairs, everything quickly fell into place.

As an extra aside, if you are using setRequired, and want to overwrite the default “Value is required and can’t be empty” message, simply add your own notEmpty validator with a custom error message as I’ve shown above.

For a list of constants each validator uses to put in your messages array see:

• 59.5. Validation Messages

The docs on the Zend Framework site on writing custom view helpers (here) are a little misleading. They say that as long as you follow the naming rules, that your helper will autoload and instanciate. The documentation give an example where the class is named My_View_Helper_SpecialPurpose. Having written my code, I found that the best way to get the class to autoload is to put the script in the views/helpers directory, and name it Zend_View_Helper_SpecialPurpose. Everything then worked with no changes needed to my bootstrap.

For those of you interested, here is my code:

/application/views/helpers/ToPounds.php

class Zend_View_Helper_ToPounds extends Zend_View_Helper_Abstract
{
	/**
	* Returns an integer value converted to pounds
	*
	* @return string
	* @param $int Integer value to convert to £ format
	* @access public
	*/
	public function toPounds($int)
	{
		return htmlentities('£'.number_format($int, 2, '.', ','));
	}
}

I can now call the function from within any view using:

<?php echo $this->toPounds(100); ?>

I hope that helps somebody.

Basically, you tell the controller which additional contexts should be available in the init function of the controller, and then pass format=<context> to tell the action to render the page in that context. The code is:

public function init()
{
	$contextSwitch = $this->_helper->getHelper('contextSwitch');
	$contextSwitch->addActionContext('saverss, 'json')
		      ->initContext();
}

You can then get anything set into a view variable json encoded by passing the querystring parameter format=json (or /format/json/), so:

public function saverssAction()
{
	$this->view->response = array('x', 'y', 'z');
}

Returns the JSON:

{"controller":"mediaman","response":["x","y","z"]}

This is really helpful when you have a number of actions that are called using AJAX from your front-end. Thanks to Bittarman in the #zftalk channel for the heads up.

More Reading…

• Zend Framework Manual on Action Helpers

As part of our layout, we want to include a generic style sheet in each page, and a custom style sheet for each controller to each rendered page. As in the previous post, we wanted effectively to run some code in each and every controller, but did not want to have to include the code in each and every controller. As we already had a FC plugin that was handling the authentication, I decided to modify this to set a view variable that can be accessed from the layout.

Basically, this process takes 3 easy steps…

1. Get an instance of the ViewRenderer
2. Initialise the view
3. Set the view variable

This is pretty straight forward when you understand what you want to achieve, but took some getting right for me, thanks again to everyone in the #zftalk IRC channel for their patience on this one!

// set a view variable with the controller name for access in the layout
// not strictly to do with authentication but it can sit here as a bonus
// create an instance of the view renderer
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
// initilaise the view
$viewRenderer->initView();
// set a view variable to be the controller name
$viewRenderer->view->controller = $request->getControllerName();

Basically that covers it, the trickiest part for me was learning to use the Zend_Controller_Action_HelperBroker to get the helper I needed to set the view variables. I hope this helps someone.

More reading…

• Zend Framework manual entry on Zend_Controller

Part of this logic means that for the site we are currently developing, every single controller used in the back-end needs to check if the user is authenticated, and if not, needs to forward the user to the login controller.  The easy way to do this is to use call the Auth model in each controllers _init function, and do the check there. What I wanted to achieve was a global site-wide check on each and every controller so that all the authentication checks are in one place.

Step forward the Front Controller plugin.

Firstly, you have to understand a little about how the dispatch process works in order to fully understand how and where to create your FC plugin. I found reading the Zend_Controller Basics page of the Zend Framework manual extremely helpful (see “More reading…” below).

The next question was where do I want the authentication to take place.  I decided that before the dispatch process was best, and so decided to bind my function at the pre-dispatch stage.  It saves the whole dispatch process from being run-through if the user is not authenticated.

So, to the code; firstly, I created the plugin that extends Zend_Controller_Plugin_Abstract.

application/plugins/AuthPlugin.php
/**
 * Application auth plugin
 *
 * @uses Zend_Controller_Plugin_Abstract
 */

class Central_Plugin_AuthPlugin extends Zend_Controller_Plugin_Abstract
{
	 public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
	 {
	 	// if not logged in, redirect to the login page
	 	// create an instance of Zend_Auth
	 	$auth = Zend_Auth::getInstance();
	 	// if not logged in
		if (!$auth->hasIdentity())
		{
			// set the new controller name to be the login controller
			$request->setControllerName('login')
			// set dispached to be false so the dispatch loop starts again
			->setDispatched(false);
		}
	 }
}

Next up, we need to load the plugin from the bootstrap:

// grab an instance of the front controller
$front = Zend_Controller_Front::getInstance();
// register a fc plugin
$front->registerPlugin(new Central_Plugin_AuthPlugin());
// go go go!
$front->dispatch();

It’s really as simple as that, I would like to investigate in the future loading the controller from the application.ini which I believe is possible. But for now, this works.

Edit:
Using the application.ini really is a much simpler way of loading your plugins… try this on for size:

resources.frontController.plugins[] = "Plugin_AuthPlugin"

More reading…

• Zend Framework manual entry on Zend_Controller
• Zend Framework Devzone Article on Front Controller Plugins