The Zend Framework has an easy way of managing sessions by creating a new instance of the Zend_Session_Namespace class. This class provides an easy to use API on the Zend_Session managed superglobal $_SESSION. By default the session data is saved to the filesystem which works perfect for simple applications using a single webserver but will be more problematic when multiple webservers are used all with their own filesystem.

A solution for this problem is saving the session data to a central database which is available to all webservers. The Zend Framework provides a class which can be used for this: Zend_Session_SaveHandler_DbTable which can be configured completely as a resource within the application.ini file.

Using the database as a central source for session data gives some other worries though:

• You have to make sure the database will be available at all time
• Clustering databases for high availability is something not all persons have knowledge on
• Managing the session tables within these databases poses some headaches when changes to the existing table are needed.

Another approach is using a memory based store like memcache, but in this post i would like to use the “new” kid in town called MongoDB, a scalable, high-performance, open source, document-oriented database. For this we are going to write a new session save handler for Zend Framework called GcLib_Zend_Session_SaveHandler_MongoDb. The source of this class can be downloaded here.

We start by creating the class GcLib_Zend_Session_SaveHandler_MongoDb implementing the interface Zend_Session_SaveHandler_Interface. This interface contains six methods we need to implement:

1. open($save_path, $session_name): This method should open a connection to MongDB and return a boolean indicating its success. In our case we do not really need the parameters for save path and session so we ignore the values passed into the method.
2. close(): This method should normally close the connection you opened in the open() method, but for convenience we just return true.
3. read($id): This method has a parameter containing the session id. With this id we will find the session data in MongoDB. Beware, this function should alway return a literal, so never return NULL or false when no session data is returned from the database!
4. write($id, $data): This method actually stores the session data in MongoDB. The id parameter contains the session id (which is the same as the value kept in the session cookie). The data parameter contains the serialized session data. These values are both stored in a MongoDB document together with a lifetime property containing the acces time. The method returns a boolean indicating its success.
5. destroy($id): This method removes the session data and returns also a boolean indicating its success.
6. gc($maxlifetime): This methods behaves as the garbage collector and removes sessions which are stale.

Note: For now the database and collection are hardcoded: db=”php”, collection=”sessions”

Zend configuration of the MongoDB save handler

resources.session.saveHandler.class = "GcLib_Zend_Session_SaveHandler_MongoDb"

resources.session.saveHandler.options.servers = "localhost:27017"

resources.session.saveHandler.options.persist = "x"

resources.session.saveHandler.options.replicaSet = "true"

Example of inline form labels

Most of these implementations use the .focus() and .blur() functions to add/empty the input value with the label. This approach has some drawbacks though:

• Submitting the form will submit the label when no custom data is entered.
• When a input field needs focus on page loading then the label is never shown.

To overcome these problems i created a JQuery plugin called inFieldLabel which adds an extra span element containing the label value and with some css this span element is projected over the input text field.
/* Inline Label class*/
span.inline-label {
position: absolute;
display: none;
}


When you start typing the span element is hided.

Usage:

1) Using default label text
$("#test1").inFieldLabel();

2) Using custom label text
$("#test1").inFieldLabel({labelText:"Type your text here..."});

3) Using an attribute value of the input text field as label text (eg. “title”)
$("#test1").inFieldLabel({useAttribute:"title"});

The full source code for this plugin can be downloaded here (updated). An example of its usage can be seen here (updated) or can be downloaded here as a packaged zip file (not updated).

This part explains how to send the data from the CKEditor instance back to the Air application, using a new CKEditor plugin called airsave. The sources for this part are available as an update to the sources of part 1.

It all starts with a new CKEditor plugin, “airsave”. For this a new directory airsave is created within the ckeditor\_source\plugins directory. In this directory a new file plugin.js is created where i copied the content from the standard save plugin with the following change to the execute function:
exec : function( editor ) {
// When executing "fire" event "airSave" containing the editor data
editor.fire( 'airSave', editor.getData() );
}

After all changes are applied, the plugin is registered to the CKEditor by adding the following line to the \ckeditor\config.js file:

config.extraPlugins = 'airsave';

In the same file the newly created AirSave button is added to the toolbar.

When the AirSave button is pressed an event called “airSave” containing the html content of the editor is fired and this event can be catched by registering an event listener with a callback function to the CKEditor instance:

var aireditor = CKEDITOR.replace( 'editor' );
// Add Listener for the "airSave" event...
aireditor.on( 'airSave', function( evt ) {
window.parentSandboxBridge.saveContent( evt.data );
} );

(see src\assets\ckeditor\aireditor.html for the complete code).

The event listener is registered in the non-sandboxed part of the Air application, so i need to call the saveContent function in the sandboxed src\assets\ckeditor\index.html file using the parentSandboxBridge.

This “sandboxed” saveContent function is calling another javascript function sendContentToAS3 which is linked to an actionscript function in the onApplicationCompleteHandler function during application start up.

Download the CKEditorOnAir_Update.zip file for full example code.

After some searching on the web, i found out that it should be possible to use javascript/html editors like CKEditor within Adobe AIR, but little info was available on how to do that.

So this blog post describes the steps i have made to successfully integrate the CKEditor with Adobe AIR, called CKEditorOnAir. Download CKEditorOnAir.zip for full example code.

Although the code samples should work within Adobe AIR 1.5 i am using Adobe AIR 2.0 for this example. Furthermore i have used a branche of the CKEditor due to the fact that the current release of CKEditor 3.3.x has some difficulties with the Adobe AIR security constraints. CKEditor developers are working on these issues, and there efforts so far can be found here.

Below is a screenshot of the application, which contains a textarea field for editing raw html content, a button for loading the content from the textarea to the CKEditor instance.

CKEditorOnAir application screenshot

I will not go into detail here about the configuration settings (toolbar, color etc.) used for the CKEditor instance, but you can find them in the “src/assets/ckeditor/config.js” file within the CKEditorOnAir.zip.

So now you know what the result will be, lets dive into the wonder world of application sandboxes, non-application sandboxes and the bridges which connects them.

Because the CKEditor sources are doing all kind of wonderfull javascript things which are prohibited by Adobe AIR it is not possible to load a html file with a CKEditor instance directly with the actionscript HTMLLoader class into the AIR runtime. If you want to know more about these Adobe AIR security constraints, i suggest to read some Adobe documents about this topic.

Two files are necessary to load a CKEditor into Adobe AIR and communicate with the CKEditor API from the AIR API and vice versa:

1. index.html (running in the application sandbox)
2. aireditor.html (running in the non-application sandbox)

The index.html file is loaded by the actionscript class HTMLLoader and from within this file you have access to the complete Adobe AIR API. You can also call javascript functions within this file directly from actionscript.

The aireditor.html file is loaded from the (sandboxed) index.html file using an iframe and has access to all kind of features which is needed by the CKEditor including the CKEditor API.

Two separate worlds, so how do we communicate between those worlds? Fortunately Adobe AIR creates two interfaces on every loaded html window: parentSandboxBridge and the childSandboxBridge.

This way we can expose javascript functions from the index.html to the loaded contentWindow of the iframe, but also call javascript functions which are exposed by the aireditor.html file in the same way.

aireditor.html example:
var childBridgeInterface = {};
childBridgeInterface.setContent = function(content) {
aireditor.setData(content);
}
window.childSandboxBridge = childBridgeInterface;

The above “setContent” function can now be called from index.html file by using the childSandboxBridge of the iframe contentWindow:
document.getElementById("sandbox").contentWindow.childSandboxBridge.setContent(content);

Check the complete sources of index.html and aireditor.html in the CKEditorOnAir.zip. Both files can be found in the “src/assets/ckeditor” location.

In another post i will explain howto send the content from the CKEditor instance to actionscript using a CKEditor save plugin. Have fun!

The PHP OCI extension for Oracle provides two execution modes: OCI_DEFAULT and OCI_COMMIT_ON_SUCCESS. The default execution mode is OCI_COMMIT_ON_SUCCESS and this mode will automatically commit any (successful) SQL statement. The OCI_DEFAULT mode is mostly used when multiple statements are executed in one batch and should be committed (or rolled back) as one transaction.

Although most PHP developers (and PHP frameworks like Zend Framework) are using the OCI_COMMIT_ON_SUCCESS execution mode as their default mode, I personally think that you should not use this mode: Using the OCI_COMMIT_ON_SUCCESS mode will auto-commit any successful SQL statement, even when a SELECT statement is executed!

When selecting data in Oracle the results will probably come from the Shared Global Area (SGA memory). Only when the requested data does not reside in the SGA some file I/O is needed to fetch the missing data from disk to the SGA.

Now I don’t know why anybody would want to commit a SELECT statement (no data modifications are made), using the auto-commit will probably have an effect on the total performance of the system.

Below is an example proofing that a select statement in auto-commit execution mode is issuing a transactional commit. For the example explained below the following software is used:

• Oracle Express Edition
• PHP’s OCI extension
• PHP 5+

The following query describes the table definition used:

create table execution_mode
( mydate date
, some_text varchar2(200)
);


And here is the PHP script (Example.php):
<?php
$conn = oci_connect('username', 'password', '//localhost/XE') or die;
$data = 'Hello world';
// Insert a record
$sql = "INSERT INTO execution_mode
(mydate, some_text)
VALUES
(SYSDATE, :text)";
$stmt = oci_parse($conn, $sql);
oci_bind_by_name($stmt, ':text', $data, 200);
// Use OCI_DEFAULT execution mode,
// when failure occurs rollback any changes
if ( !oci_execute($stmt, OCI_DEFAULT) ) {
oci_rollback($conn);
echo "Transaction failed\n";
exit(1);
}
// Determine total records by select count(*)
$sql = "SELECT COUNT(*) AS num_entries FROM execution_mode";
$stmt = oci_parse($conn,$sql);
// Bind count to $num_entries variable
oci_define_by_name($stmt, "NUM_ENTRIES", $num_entries);
// Whoops forgot OCI_DEFAULT, so OCI_COMMIT_ON_SUCCES is used!
oci_execute($stmt);
// Fetch data
oci_fetch($stmt);
// Issue a rollback
oci_rollback($conn);
// Too bad data has already been commited by the select count(*) statement!
?>

Checking the data in table execution_mode with SQL*Plus reveals that the record is inserted and commited:

Conclusion: always use OCI_DEFAULT as your default execution mode. Commit (or rollback) your transactions manually when and where appropriate.

Vote for my proposed solution to enable to set the default execution mode within the Zend Framework Oracle database adapter!

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"

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

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.

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.

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.