In this second part of my Zend Framework quest, i will dive in the wonderfull world of application resource plugins. Zend_Application provide several standard resource plugins for database access, session management, routing etc. You can find more info about these standard Resource Plugins here.

The fun part of these Resource Plugins is that they can be configurated completely within the application.ini (or application.xml) configuration file and are loaded automatically by the Application Bootstrapper.  For example you can define a new Route resource “myroute” referencing the module/controller/action without writing any code like this:

; Router resources
resources.router.routes.myroute.route = "hello/:myname"
resources.router.routes.myroute.defaults.module = "mymodule"
resources.router.routes.myroute.defaults.controller = "index"
resources.router.routes.myroute.defaults.action = "index"

Which will route the following url “http://localhost/hello/world” to the standard controller action from the “mymodule” module, with the request parameter “myname”  filled with “world”.

While Zend Framework ships with a number of standard resource plugins, the intention is that developers should write their own to encapsulate their own initialization needs. So lets begin with our own custom resource plugin for initializing application logging using Zend_Log.

The first step is to define a plugin-path and prefix path for the new custom resource in the application.ini configuration file (preferably somewhere in the beginning), like this:

pluginPaths.Custom_Resource = APPLICATION_PATH "/resources"

When the new resource class starts with “Custom_Resource”, it will be automatically loaded by the Bootstrapper.

Create a new file Logger.php in the APPLICATION_PATH/resources location containing the following code:

class Custom_Resource_Logger
extends Zend_Application_Resource_ResourceAbstract {
}

The new resource plugin should now accept options to the constructor, have mechanisms for setting and retrieving options, have mechanisms for setting and retrieving the bootstrap object, and an initialization method.

Now the basics are set, it is time to think about what the new logger resource can do, or better, define the configuration options. Here are the options:

1. “registry”
2. “output”
3. “priority”
4. “file”

Although Resource Plugins are put in a bootstrap container (which is basically an instance of Zend_Registry) they are not globally available. This means you need access to the bootstrap in your code to load the resource. To overcome this “problem” the Zend_Log instance is registered with the name provided in the “registry” option. This way you can get your Zend_Log instance like this:

Zend_Registry::get('[registry-option]')

The “output” option let you configure where the log messages are send: The available values are “file” or “firebug”.

The “priority” option will filter the log messages to the default Zend_Log priorities levels 0-7.

The “file” option finally defines the file location when you choose “file” as the output. It is possible to use a date within the filename, using the replace needle “%d”.

The full implementation (source) of the Logger.php file can be found here.

Just the final step to completion, registration off the new Resource Plugin to your bootstrap. Again this can be accomplished by adding the following line to your application.ini configuration file:

resources.logger[] = ""

The application.ini configuration should now look like this:

; Custom resource plugins
pluginPaths.Custom_Resource = APPLICATION_PATH "/resources"
; Logger resources
resources.logger[] = ""
; Option used for Global Registry location
resources.logger.registry = "Zend_Log"
; Use for output option: firebug or file
resources.logger.output = "file"
; Priorities available: 0=[EMERG]/1=ALERT/2=CRIT/3=ERR/4=WARN/5=NOTICE/6=INFO/7=[DEBUG]
resources.logger.priority = 3
resources.logger.file = APPLICATION_PATH "/../tmp/app-prod-%d.log"

It has been a while since i last wrote a post about working with the Zend Framework and the, then rather new, package Zend_Amf. The project structure was an attempt to integrate the Zend MVC with Zend Amf (and of course try out some new features in the Flash player 10).
Since that post, Zend has released some major releases with some rather big changes, like the Zend_Application package combined with the Bootstrap class.

Because i am not a real PHP programmer (consider myself as a junior in that area), it is rather difficult to learn all the ins-and-outs of the framework and i rely heavily on what other people write on the internet about the several topics considering the Zend Framework.

So i decided to bundle all my findings into one project setup and publish the sources on Google code. This way i always have access to these sources and i can refer to them within coming blog posts.

The first thing i did was setting up a project structure like the one shown in picture 1:

figure 1: project outline zend framework

The root of the project contains besides the standard application, library and public folders, also folders for future unit tests and temporary files (caching, logfiles).

The library folder needs some explanation. Normally this folder contains a Zend folder with the Zend Framework classes. I decided not to hold a complete copy of the framework in my own Google code subversion repository, but instead a have set a subversion property svn:external, linking to the Zend Framework subversion repository.

When checking out the code from Google code, the Zend Framework classes will also be checked out (and automatically updated, when the svn:external property is updated) in the library folder.

So let start with the application folder structure. As shown the folder contains  a configs, default, modules and resources folder. When you follow the project setup explained in the Zend Framework Quick Start, you will find some differences with the setup i use. For example all contents of the default folder are found in de Quick Start directly under the application folder and the Quick Start setup is missing the modules and resources folders.

I shall try to explain the rest of the project contents in some later posts, so in the meanwhile check out the sources and let me know what you think of it.

Here is a screenshot of what will be shown when the sources are succesfully installed within your local webserver.

Frontpage zend framework demoground

In one of my earlier posts i described a method for uploading files using the RemoteObject class found in the Flex SDK. For the “back end” i used the still very popular amfphp implementation of the AMF protocol.

Wade Arnold the maintainer of amfphp is also involved in another implementation of the AMF protocol which is shipped with the Zend Framework. After reading some blog posts about this “new” package called Zend_Amf, i decided to give it a try.

Download ZendAMFUpload.zip for full example code.

I started my quest with downloading of the latest Zend Framework library, which is now at version 1.7.8 and followed the instructions of the Quickstart guide, which can be found here.

I also found a great post from Piotr Walczyszyn about how to merge the Zend_Amf package within the Zend Framework MVC structure and i used this approach as a starting point for my own example, but made the following changes compared to the tutorial of Piotr:

1)
Because i don’t use a database within my example i removed all code related to the config, database and registry from my bootstrap.php file.

2)
Somehow the disableLayout call in the MessageBrokerController init function Piotr provided resulted in an error, so i removed this line.

3)
Instead of putting my data objects into a dto folder i used a folder named vo. It is the same, but i am used to call my remote data objects Value Objects.

4)
During my quest i stumbled to some strange behaviour when sending Typed Objects (FileVO) from my flex client to the service layer. According to the Zend_Amf documentation you could use $_explicitType within a ValueObject for mapping serverside PHP classes with AS3 classes, but this only worked for retrieving typed objects, not for sending typed objects. Finally i found these issues related to class mapping of typed objects: ZF-5755, ZF-5885 and ZF-6130, and decided to use the $server->setClassMap call in my MessagebrokerController.

Here is the code i ended up with:

MessagebrokerController.php

class MessagebrokerController extends Zend_Controller_Action {
// Initialise controller with no view renderer
public function init() {
$this->_helper->viewRenderer->setNoRender(true);
}
// amf action
public function amfAction() {
$server = new Zend_Amf_Server();
$server->addDirectory(APPLICATION_PATH . '/services/');
// Mapping of PHP FileVO class and AS3 FileVO class
$server->setClassMap("FileVO", "FileVO");
echo($server->handle());
}
}


FileVO.php


class FileVO {
public $filename;
public $filedata;
}


RemoteFile.php


class RemoteFile {
/**
* Upload files!
*
* @param $file as a FileVO Object
* @return string
**/
public function upload($file) {
$data = $file->filedata;
file_put_contents( APPLICATION_PATH . '/uploads/' . $file->filename, $data);
return 'File: ' . $file->filename .' Uploaded ';
}
}


I kept the flex code the same as in my earlier post except for the remote service endpoint url, which should be now something like

http://[some-host]/messagebroker/amf

Download ZendAMFUpload.zip for full example code.

File upload with Adobe Flex is a common asked feature for lots of applications. There are several posts on the internet to be found which explain, in detail, how to do this.

Most of these examples however uses the http protocol to transport the binary data. With the arrival of the Adobe Flash 10 player and the new FileReference features that comes with it, it is now also possible to upload a file via a RemoteObject service call.

For the coming example it is assumed that amfphp 1.9 and Flash player 10 (Flex 3.2 SDK) is installed and running. Furthermore i am using a setup as described in one of my earlier posts about RemoteObject and AMFPHP. Download PHPUpload.zip for full example code.

Copy the services contents found in the zip to your amfphp services location (and check the amfphp/globals.php if your “vo” location is configurated to “services/vo/”).

Within your services directory a RemoteFile.php can be found with a public function upload, which require a parameter of type FileVO:


require_once ('./vo/FileVO.php');
class RemoteFile {
/**
* Upload files!
*
* @param FileVO $file
* @return string
**/
public function upload(FileVO $file) {
$data = $file->filedata->data;
file_put_contents( 'uploads/' . $file->filename, $data);
return 'File: ' . $file->filename .' Uploaded ';
}
}


The FileVO php class has a Flex counterpart also called FileVO which is used as a so called RemoteClass. This RemoteClass has an attribute for the filename and filedata (ByteArray).

No we are ready to create the service class for the upload example, this class will be named RemoteFileService and extends the RemoteService super class.public class RemoteFileService extends RemoteService {
private static var phpServiceClass:String = "RemoteFile";
//constructor
public function RemoteFileService(amfChannelId:String, amfChannelEndpoint:String) {
super("remotefileService","amfphp", amfChannelId, amfChannelEndpoint);
}
// Upload function
public function upload(file:FileVO):void {
remoteObject.source = phpServiceClass;
remoteObject.upload.addEventListener(
ResultEvent.RESULT,handleRemoteMethod);
remoteObject.upload(file);
}
// Remote result handler
protected function handleRemoteMethod(event:ResultEvent):void {
var uploadStatus:String;
uploadStatus = event.result.toString();
Application.application.dispatchEvent(
new RemoteResultEvent(RemoteResultEvent.UPLOAD_STATUS, uploadStatus));
}
}

The Flex application file contains a text component (which will be filled with the selected filename), a button for selecting a file and a button to start the upload. Download PHPUpload.zip for full example code.

After a succesfull upload the selected file will be placed in the amfphp/services/uploads directory (needs write privileges!) and an Alert shows a message from the server.

After reading some blogs about a relative new Flex framework called swiz, i decided to try it out some time. Swiz is a framework. started by Chris Scott, that aims to bring complete simplicity to RIA development.

To get some feeling with the framework i started to work out a login example i found on the blog from Sönke Rohde, which uses a utility for mocking service calls, which also can be found in the swiz framework. For my own example i used the following snapshot swiz-0.0.5-010609.swc with mediator and event type checking support, but decided to extend the login sample with some runtime localization features.

These localization features consist of some xml-files which can be loaded during runtime and are used for translating labels and fault messages (bad credentials).

During development of the new example i found out that the mockutility in the framework only returned a result. In a real-life application faults will occur so i copied the sources of the swiz framework TestUtil class into a new class called MockUtil and added my own mockFault and mockFaultEvent methods.

The sources of my extended login example can be downloaded here (swiz library not included!). The assets/data/users.xml file contains the mock data for the login and can be modified with your own user credentials. The assets/locale directory contains sub-directories with the localization files used.

Almost 2009! So here is something to think about.

The Paradox of Our Age

“We have bigger house, but smaller families;
more convenience, but less time.
We have more degrees, but less sense;
more knowledge, but less judgement;
more experts, but more problems;
more medicines, but less healthiness.
We have been all the way to the moon and back,
but have trouble crossing the street to meet the
new neighbour.
We build more computers to hold more
information to produce more copies than ever,
but have less communication.
We have become long on quantity,
but short on quality.
These are times of fast foods,
but slow digestion;
tall man, but short character;
steep profits, but shallow relationships.
It’s a time when there is much in window,
but nothing in the room.”

His Holiness The XIVth Dalai Lama

In my daytime job i am currently involved with a Flex3/BlazeDS project.The question arises to me quickly if it was possible to use Actionscript 3 RemoteObject classes with a PHP back end. A quick search with Google showed me some examples where Flex mxml in combination with amfphp 1.9 was used. This particular version of amfphp has support for AMF3 messaging protocol and therefore can be used natively with AS3 RemoteObject.

In my example i wanted to do something different by using AS3 RemoteObject classes and creating Channels at runtime, so no server-config.xml is needed during compile time.

For the coming example it is assumed that amfphp 1.9 is installed and running. for the backend service i use a slightly changed HelloWorld.php which can be found in the amfphp examples:

class HelloWorld {
/**
* Say hello!
*
* @param string $sMessage
* @return string
**/
public function say($sMessage) {
$date = getdate();
if (!$sMessage) {
throw new Exception("No message has been given",10001);
}
return 'You said: ' . $sMessage .' on '.$date[weekday];
}
}
?>

I introduced a PHP exception when no message parameter is given.
The next step involves the creation of the RemoteService super class. The constructor method is shown below (download PHPRemoting.zip for full example code).

public function RemoteService( serviceId:String
, serviceDestination:String
, amfChannelId:String
, amfChannelEndpoint:String
)
{
// Create a runtime Channelset for given Channel ID and Endpoinr URI
var amfChannel:AMFChannel = new AMFChannel(amfChannelId, amfChannelEndpoint);
amfChannelSet = new ChannelSet();
amfChannelSet.addChannel(amfChannel);
// Create the remoteObject instance
this.remoteObject = new RemoteObject(serviceId);
this.remoteObject.channelSet = amfChannelSet;
this.remoteObject.destination = serviceDestination;
this.remoteObject.addEventListener(FaultEvent.FAULT,onRemoteException);
}

All new service classes will extend this RemoteService super class and inherit all methods available.

No we are ready to create the service class for the HelloWorld example, this class will be named HelloWorldService and extends the RemoteService super class.

package remoting.services
{
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
import mx.core.Application;
import remoting.events.RemoteResultEvent;
/**
* Class that extends the RemoteService class, therefore it makes use of the default error handling for
* remote calls.
*/
public class HelloWorldService extends RemoteService {
// Static var with the PHP classname
private static var phpServiceClass:String = "HelloWorld";
//Constructor
public function HelloWorldService(amfChannelId:String, amfChannelEndpoint:String) {
super("helloworldService","amfphp", amfChannelId, amfChannelEndpoint);
}
//
public function say(msg:String):void {
remoteObject.source = phpServiceClass;
remoteObject.say.addEventListener(
ResultEvent.RESULT,handleRemoteMethod);
// call the PHP method
remoteObject.say(msg);
}
// Result handler
protected function handleRemoteMethod(event:ResultEvent):void {
var helloworld:String;
helloworld = event.result.toString();
Application.application.dispatchEvent(
new RemoteResultEvent(RemoteResultEvent.HELLO_WORLD, helloworld));
}
}
}

There is only a resulthandler implemented for the remoteobject call, because the fault handler is already implemented within the RemoteService super class. Important thing is the static var phpServiceClass which contains the name of the PHP class which will be binded to the remoteObject.

Now the plumbing is ready (download PHPRemoting.zip for full example code) it is time to create the Flex application file. This example application has a TextInput box for the message and a Button to call the remote method.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="vertical"
creationComplete="init();">
<mx:Script>
<![CDATA[
import remoting.events.RemoteExceptionEvent;
import remoting.events.RemoteResultEvent;
import remoting.services.HelloWorldService;
import mx.controls.Alert;
//
private var amfChannelId:String = "my-amfphp";
private var amfGateway:String = "http://localhost/amfphp/gateway.php";
private var service:HelloWorldService;
// Initialization
private function init():void {
this.addEventListener(RemoteExceptionEvent.REMOTE_EXCEPTION, handleRemoteExceptionEvent);
this.addEventListener(RemoteResultEvent.HELLO_WORLD, handleRemoteResultEvent);
// Create a new service instance
service = new HelloWorldService( amfChannelId, amfGateway );
}
// Button action handler
private function clickHandler():void {
service.say(msg.text);
}
// Result handlers
private function handleRemoteResultEvent(event:RemoteResultEvent):void {
Alert.show(event.message);
}
private function handleRemoteExceptionEvent(event:RemoteExceptionEvent):void {
Alert.show(event.message);
}
]]>
</mx:Script>
<mx:TextInput id="msg"/>
<mx:Button label="say something" click="clickHandler();"/>
</mx:Application>

When no text is provided the PHP class will throw an exception which is shown in the Alert box. Just try it out.

Adobe finally released it’s 1.0 version of AIR, so let’s go to work and create great looking applications. But how on earth do we deploy these applications to the public?

When downloading the AIR SDK a sample is provided for installing and deploying air applications using the badge installer. This badge installer consist of a badge.swf file and some javascript which can be used within html and automatically installs the right version of the Adobe AIR runtime followed by your application.

When using flash within (x)html i personally prefer to use the SWFObject javascript file so here are the steps involved of deploying AIR applications using the badge installer and SWFObject.

First of all you need to change your webserver configuration to add support for the AIR mime type by adding the following line to your, for example, Apache configuration file:

AddType application/vnd.adobe.air-application-installer-package+zip air

Now it is time to use SWFObject. Simply include the swfobject.js Javascript file in the head section of your html, then use a small amount of Javascript on your page to embed your Flash movie. In our case this will be the badge.swf file from the AIR SDK. A complete example with the necessary variables for installing the AIR 1.0 runtime and an example “hello world” AIR application is shown below.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Deploy Hello World</title>
<script type="text/javascript" src="swfobject.js"></script>
</head>
<body>
<div id="flashcontent">
This will hold the flash content
</div>
<script type="text/javascript">
// <![CDATA[
var so = new SWFObject("your/path/to/badge.swf", "badge", "217", "180", "9.0.115", "#FFFFFF");
so.addVariable( "appname", "Hello World" );
so.addVariable( "appurl", "http://your-host/HelloWorld.air" );
so.addVariable( "imageurl", "test.jpg" );
so.addVariable( "airversion", "1.0" );
so.write("flashcontent");
// ]]>
</script>
</body>
</html>

Never thought that this would happen, but i have just started a weblog.

Hopefully it will last for a long time, but hey nobody knows where this blog train will lead us.