With Zend_Application you can not only setup all the components required (Zend_Table, Zend_View, Zend_Navigation, ecc) but you can also setup your own custom plugin, called Resource.

In the Zend lingo a Resource is a plugin loaded by the Zend_Application and configured through the application.ini file or in the Bootstrap.php class.

A Resource can be used to setup a standard Zend component, routes, controller plugins or your custom component.

Lets see how.

Use the Bootstrap class

When you create an empty Zend Framework project with the zf create project command, you'll find a Bootstrap.php file in your application folder.

In this file there is a Bootstrap class that you can use to define your own resources by simply creating a method with the _init prefix.

For example:

This setup a resource called Doctype.
This resource simply set the doctype property in the view (which is a resource too).

With the $this->bootstrap('view'); line, the Doctype resource requires the initialization of another resource: the View. In this way you can define dependencies in your resources.

You can even override the definition of a standard resource with your own, for example:

In this way Zend_Application will use the view resource defined in your _initView method instead of the standard one.

With this method you can customize your Zend Framework with ease, but when you need to configure a standard component, like the db connection, there is a better approach: using the application.ini.

Use the application.ini file

Another gift of the zf create project command is the application/configs/application.ini file.

It contains all the configurations options of your application.
You can for example use it to configure your db:

You could use either the Bootrap or the application.ini method for this task, however I personally prefer this method when configuring parameters that changes across the servers (development, testing, production) like the include paths or the db connection options.

A better approach: Create a custom resource class

To improve reusability, you can create a custom resource class, that can be easily distributed and configured through your application.ini.

Its simple: in your library create a MyResource folder and a Custom class:

In the init method, you can initialize your resource, and return it.
The object returned will go in the resources repository, and it will be accessible with the $bootstrap->getResource('custom') call in the other resources. (hint: is case insensitive)

To use your newly created resource, you can simply put that in your application.ini:

That's all.

A resource can take configuration options too, for example:

Zend_Application will automatically initialize a resource when you set a configuration option in it.
If our resource doesn't expect a parameter, you can simply write resources.*resourcename* = true, like in the previous example.

You can access the options from within the resource through the $this->options variable. You can also define a setter method for the option:

You are now ready to build your distributable plugin for Zend Framework, for other examples see the Zend/Application/Resource folder in the framework distribution or my MadaConsole resource.

Building Facebook applications with Zend Framework, I've needed a debug console that can shows messages even in a Facebook canvas page, through an ajax request or a redirect.

For this purpose I've build a custom plugin for ZF that fits the need: it will sit under your pages and shows all your dumped object, messages and queries.

MadaConsole debug console

Usage is really simple: copy in your library and add the plugin in your Boostrap or application.ini.
For a detailed guide see below.

Features

• Trace custom messages easily: debug("A debug message");
• Dump variables easily in your code with the pass-through function:
  Before: array_count_values($arr); After: array_count_values(debug($arr));
• Shows the queries executed by your Zend_Table
• Shows debug messages even through redirects or ajax requests

Install

Installing the plugin is simple:

1. Download the archive: MadaConsole
2. Unzip the library folder of the archive in the library folder of your Zend Framework application

Then you can configure it with two methods: through your application.ini or in the Bootsrap class.

Method1: application.ini

Add those lines after [development : production]:

pluginPaths.MadaConsole = "MadaConsole"
resources.console = true


Method 2: Bootstrap class

Add this method:

Usage

Now in your code you can do:

With the pass-through functionality you can simply add the debug() function in your existing statements with ease: $var = debug(my_func($foo));

To see the debug output when you do an ajax request, you can open a page of your choice in another browser window: the debug console will show all the messages site-wide.

Downloads

MadaConsole plugin
MadaConsole example Zend Framework project

How the debug console looks like

Facebook basics

You can integrate your application with facebook in two way: with an IFRAME (using XFBML) or with FBML.
(If you are already familiar with how a Facebook application work you can skip this step)

You can embed your content in a Facebook page through FBML or use an IFRAME

Build your website using FBML tags

Facebook will be a proxy between your server and the user's browser: it will load a page form your own server like a normal browser, parse it, "enhance" it with his components and then embed it in a Facebook page. You will use standard HTML tags plus FBML tags.

Pros:

• You can use almost standard HTML, but with some other tags like: <fb:comments ... />, <fb:wall ... />
• Feature rich: with a simple tag integrate wall, comments, tabs, dashboard and many others components (Complete list of facebook tags)
• The url in the browser follow the navigation
• Faster when you need data from facebook database (groups, friends, etc.)

Cons:

• Slower page load times: restart the facebook chat at every request
• Can't use standard JavaScript, only FBJS that's almost equals but your existing scripts and libraries won't work
• Its losing ground: Facebook is trying to take IFRAME/XFBML on par

Embed using an IFRAME

Use an iframe: just build a standard web site and let FB embeds it in an iframe

Pros:

• Better ajax support: you can use standard javascript, html and css
• Easy to debug, its just a standard web site
• Faster page load times

Cons:

• Less features than with FBML (but XFBML is rapidly improving)
• Slower when you need data from facebook database (eg: user's friends, groups, etc.)
• The url in the browser doesn't follow the navigation
• A bit more complex

We'll start with FBML since its easier to use and to find help about on the forums.
However take a look at XFBML in the future, since the Facebook team has really improved it recently and they are trying to push them on par.

See facebook wiki for further details on the differences between FMBL and IFRAME.

Integration

First of all, setup your FBML app and write down your api key and secret key.

Just follow the onscreen instructions or the wiki, but care attention to the Canvas Page URL:
it is something like: http://apps.facebook.com/*APPLICATION_NAME* and it is the url through the user can reach your app.

While the Canvas Callback URL (for example: http://www.yourserver.com/fbapp) its the address of your own web server, where you'll deploy your application.
With a dynamic dns service like dyndns you can create a domain name that map to the public address of your development machine, so that you can host your app on your dev machine while allowing Facebook to reach it.

Facebook will map every canvas url: http://apps.facebook.com/*APPLICATION_NAME*/foo to your callback url: http://www.yourserver.com/fbapp/foo

After you have done with the setup, you can use the official PHP client to interact with Facebook.

First, set up an empty Zend Framework project: you can use the Zend Studio for Eclipse wizard or the new Zend_Tool command line.

Use Zend Studio wizard to create an empty Zend Framewrok project

Then, download the client and copy the files in the php folder of the archive to the library/facebook folder of you Zend Framework project.

Now you can start using the client.

The Controller

To start, write in your controllers/IndexController.php:

The line: $err = error_reporting(E_ERROR); is needed to hide some strange php notices from the facebook.php file.
In the line 12 we instantiate our client with the api key and secret taken during the application set up.
With the require_login method you can require the user to "add" your application.
Notice that many api features are available only if the user has added the application.

Then in your Zend actions you can call every standard method of the api with the
$facebook->api_client variable, for example:

See the complete list of methods on the wiki and try them with the API console tool.

The View

Now that you know how to interact with Facebook, you can show a simple page containing the "Comments box" component.

In your layouts/main.phtml file write:

As you can see we don't have to put the standard html opening tags in your layout (<html><head>...) since Facebook will load the page from your server and embed it in his own HTML canvas page.
We had also used our first FBML tag: <fb:title> to set the page title in the browser titlebar (we can't use the ZF headTitle() method here).

Now create a view script for your index action of the index controller views/scripts/index/index.phtml:

This will place a comment box in your page. Notice that the returnurl property need to point to your canvas url and not your callback url. (substitute *APPLICATION_NAME* with your canvas url)

To experiment with the various <fb:* > tags use the FBML console.

Now you can go to your canvas url to see the result:

Your first Facebook app with Zend Framework

In the HTML source of the canvas page you can see the original FBML used to generate the page and sometimes some errors/warnings.

Javascript and CSS

You can embed JavaScript in your FBML like in HTML, but only a special flavour of JavaScript: FBJS.
It is almost like the standard one, but there are some differences and your existing scripts and libraries won't work.

If you want to embed an external .js file, you'll have to specify the absolute path. Not only: Facebook will keep a copy of your script, even if you modify it, so you'll have to put a timestamp in the url to force a cache refresh.

For example, if you want to embed a script in your index.phtml:

In this way Facebook will load the script from the url: http://www.yourserver.com/fbapp/scripts/js.js?v=1231707071.
When you'll edit the file, the number will change and FB will reload it.

The same apply to CSS:

CSS in FB is almost standard, but use absolute urls.
Also be sure to write clean CSS, otherwise the Facebook parser will sometimes hang without and explanation.

Make things easier

We can use a base controller class.
In library/FacebookController.php write:

In this way, our IndexController can be rewritten in this simplier way:

We had made IndexController inherit from FacebookController, and used its method requireLogin, without requiring to set up the Facebook client.

Not only:
with the $simulateFb variable set to true you can preview your site outside the Facebook canvas page without requiring the login (but you'll not see the FBML components).

With $useTestApplication you can use a different pair of api key and secret for the development, while keeping your main application safe. (you need to set up another app to obtain the keys)

Also the FacebookController will allow the standard Zend Framework _redirect method to work and will bind Zend session to the one of Facebook.

Finally in the last line we set up the charset encoding to be sure it will be the same of the Facebook canvas page.

Thats all:
now download the tutorial sources and start building your own Facebook app.

"Static typing is Communist Bureaucracy".

In short: since we (should) have pervasive testing, Static Typing is only more testing. However, a comment is enlighting:

I'm finding this logic hard to follow. Testing is good, coverage is good. Static typing is, among other things, a way to have the compiler test your code for type issues. Since we like testing, this makes static typing good, right?

But Static Typing not only prevent you to do mistakes, like typos, it allows your IDE to know what you are doing:

Dynamic Static Typing speeds up development because there is physically less to type since ctrl+space and ctrl+2 write the declarations for you.

Its seems obvious to me that Dynamic Typing is worth the catch only for a quick start or for learning.
Since almost all of the dynamically typed languages (like Actionscript, Perl, Php) have migrated to some kind of Static Typing (eg: Type Inference), there should be a reason.

Periodically, a new Dynamically Typed language spawn, attracting junior/tired programmers with the mirage of the simplicity and the less-to-type-ing, riding the hype until his young audience grows and start doing large projects hoping not to call a function with the wrong arguments.

Only then they realize the big truth: Static Typing is just more informations in the source code.
And more information means less wondering-what-object-was or what-was-the-method-name-and-parameters or who-instantiate-this-object, not to mention static analysis.

And hey, they have invented Javadoc-like documentation and Annotations just to add some more information, why remove one of the most important?

Will be formatted like this:

Variable types supported are: Arrays, Objects, Recordsets and XML Resources.

Since CakeAMFPhp is a beta, I've found some problems, for which I've found a quick fix that I'll explain shortly.

To start a CakeAMFPhp project, simply download the required libraries as explained in this tutorial. (If you are new to Cake you should also see this)
Then in your controller, for example GalleriesController, put this:

In the line 11 we call the automatic method table constructor of AMFPhp: it read the javadoc-like comments in the file and do all the magic:

The @access remote tag specify that the getGalleries method is callable from flash:

The getGalleries_count() method is needed for the pageable recordset:

getGalleries return only the first 25 row from the database. When the data is loaded in flash, rs.getLength() method return the value from getGalleries_count(). getItemAt return an item or a future, we check if the item is loaded in the line 8. If the item isn't from the ones loaded, it is automatically requested from the server when we call getItemAt. When it arrives, the modelChanged method is called:

in the info object there are the rows received, you can configure Flash to get only the item required or the page containing it.
That's all, simply add the @access remote tag, a *methodname*_count method and it works.
You can find more information on pageable recordsets here.

The _arrayft is required for the issue I've talk about before: CakeAMFPhp 0.6 does not support sending recorset to flash, so this method is required to transform the data returned by the Cake database abstraction layer into a AMF-compatible recordset:

For performance reason, it is suggested to use a 0 'recursive' value in the find(..) call.

You can be sure a movie will be loaded appending a query string to the file name:

You can force the user to reload a movie when you release a new version:

And use a .htaccess file (ModRewrite required):

Only when you change the VERSION variable (pass it with flashVars) the movie will be reload, otherwise it will be loaded from the browser cache.
 

You can make cacheable a file downloaded through php:

Be sure to set the correct content type:

Without Last-Modified or ETag headers flash doesn't cache the files.