Here's the list of the parts of the series:

• Part 1 - introduction, sample usage
• Part 2 - problems in making an event-based ajax callback model (and his solutions)
• Part 3 - the use of JSON in the framework
• Part 4 - implementation of the Scriptifiable interface
• Part 5 - implementing the Remotable interface

You can download the latest version of his Ajax framework directly from his blog.

I have been answering a lot of email requests for how to get started with a Bebo application. Since applications can be written in any language that supports interaction with the Bebo REST API, developers have a lot of choices in how they build their application. The focus of this article will be on the "officially supported language" - PHP.

He defines the parts of the application first (the callback, canvas page, profile box, invitation and news stories). Much like the Facebook API, the Bebo system has you host the application on your own servers and use their developer libraries to interface with their systems. He makes a simple application that has a "story" published to it that shows to each visitor.

He also tosses in a method for knowing a bit more about the user - like if they've just added the application, if they're a normal user or if they've just removed it from their application list.

It's a common sight: taking an array and running (well, walking) its elements through a particular function. Luckily, PHP provides a simple yet powerful function to overcome this: array_walk().

They include an example, giving a sample "some_function" the array_walk method uses when it's called, replacing a foreach (or other type of loop). Plus you can specify an object with the callback to run it against a method inside a class too.

The way how events are raised and how listeners are attached on the events is a part of a core in many modern applications. It plays an important role in some enterprise design patterns (MVC, for example).

He starts with the basics of event handling - some of the terms and descriptions of basic functionality that any good event handler would have. He describes the most common setup of an event-interaction relationship. Then, it's on to the code, showing first three different ways to call functions (by name, by variable, and by callback).

He finishes it off with a functional example that responds to a a call to fireEvent (five times) and handles each by calling the function in the callback information (myFunction).

If you wondered an API that requires polling isn't a very good thing for scalability. On my current setup I can pretty easily handle about 20 status requests per second on top of my normal traffic, the problem is its not hard for a bad polling implmentation being run by one user to make that many requests.

To solve this problem im adding an addition to the Webthumb API that will allow you to skip polling all together. The basic idea is that your make an API request and when your thumbnail is complete i'll make a GET request back too your server telling you that the request is complete.

It's a simple matter of including a new "notify" tag in the XML message to the server with a URL to make the callback to. He even includes some sample PHP code to get you started with the new feature. The script handles the automatic download of the thumbnails when called from the WebThumb service.

He's been working on several issues:

• fixing issues with MySQL drivers
• updating transaction support to add SAVEPOINTS
• integrating a debug callback mechanism

The only two bug reports I am currently hoping to get resolved before the next release are: a MySQL issue getting the last ID and a problem with an internal datatype.

Keep an eye out for his next release.

He starts off by looking at the filter callbacks, looking to make "drag and drop-able" plugins for his setup. He notes that, right now, you'd have to call a plugin to perfom an action, making for a good bit of load depending on the application structure. It also means that you have to change the Controller to add a new plugin ("...which doesn't seem like a very RAD approach to me").

So in order to streamline such plugin callbacks, I created a function inside SpliceIt!, that allows plugins to hook into any AppController event, such as beforeFilter, afterFilter, beforeRender, etc. in order to make their own changes to the controller. So a Themes plugin can easily change the Controller::view and a Statistics plugin can make calls to a Model.

He gives the code for the function as well as an example of how to use it in your app.

Moving on, he looks at his next issue to overcome - inter-plugin communication:

Generally spoken Controller::requestAction() isn't a bad way to exchange data between controllers. It's a clean interface and you don't have to plan in advance what data should be exchangeable and what data should not. However, there are a couple problems with it.

His solution involves the creation of an entirely seperate ApiController pattern. Of course, he provides examples, specifically related to his SpliceIt! application.

The groundwork is laid first, giving a simple "Hello world" example to show how the code flows. They show how the buffering system works and how to use a callback function to modify the contents of the buffer before outputting (including a full replace function to text within the buffer from an array). They follow that with a look at creating your own HTML tags and using the gzip compression functionality to speed up your pages.

You can either check out the HTML_template_IT homepage for more or just grab it directly.