From a technical perspective, the website was pretty trivial, however I was able to experiment with the Zend Framework's Flickr web service implementation. Caching the images and resizing them was a must since Flickr doesn't offer great options with the image presets (unless you ask people to upload at a special resolution... which is no fun!)

Building an AJAX slideshow that's driven off of Flickr meant I didn't have to write any upload-image code for the client. Furthermore, they can use Flickr pools during the conference to create an ever-up-to date gallery.

I'll be releasing this as a WordPress plugin that's a little more user friendly, however if you're doing something similar and need a hand, leave a comment and I'll send you what I wrote.

The last comment by Martin noted that Zend_Db still had some unresolved issues for over a year.

Matthew's response was that this was a community project and that priorities are dictated as such. Personally, this doesn't affect me because I'm hedging my bets on Doctrine as an ORM layer for PHP development.

I like Matthew's response because the Zend Framework's philosophy encourages the development of loosely coupled components wrapped up in a development philosophy that encourages open contributions, financial backing (thanks to Zend, IBM, Sun and others), Unit Testing and project transparency. Here's where things go a little wonky.

Partnership with the Dojo community

While I really enjoy the implementation of Zend_Form on the server side. It allows multiple configurations, supports validation and while the decorators are a bit obtuse, on a whole, the Zend_Form libraries thin out controllers and encapsulate the concern of data entry in a clean manner.

In this point release, however it seems like there's been a whole outgrowth of Zend_Dojo_* classes that cater to doing AJAX development with the Dojo stack. I'm not sold on Dojo as a client-side framework. Past experience with it has left me trying to sort out a large, over-specialized collection of patterns that almost do what I want but not quite. I also don't like the coupling that occurs between the data set, the client-side validation and the magic rendering of panels (like Accordian's and content panes).

An alternative architectural approach

I would rather write the events, the theme, the data and the validation separately and reduce duplication in each of those patterns rather than in the UI pattern as a whole. In short, I think they've abstracted the wrong part. The same example can be seen in ASP.NET form validators from two years ago.

With Prototype, I can rapidly mock out a site with the functional requirements and use Script.aculo.us to accent the presentation with animation. My functional specification isn't muddied with fancy visuals and it lets me focus on the event handling, validation and end states rather than the fancy effects.

By using Zend_Dojo, you won't be tempted to build a well-exposed Service Layer from Zend_Controller. The advantage here is that you lead development towards service-orientation. If you need to write a Flex front-end, or a whole new business-tier, you at least have the beginnings of a web service, whereas if your working with Zend_Dojo's declarative templating syntax, you're already coupling the events, validation and data into heavily abstracted UI patterns.

This approach doesn't lead development towards the production of a refined Service Layer, but to a specialized Dojo-friendly interface with markup-generation from Zend_Form classes into Dojo markup. I would rather see a Zend_Form Service API where developers can send / receive JSON messages to inherited Zend_Form and then have the Dojo community write an Adapter that would send / receive messages from Dojo widgets.

A year or two from now, I wouldn't be surprised if people will look at the same Zend bug tracker, asking where support for Dojo went after the Zend team jumps to the next cool Javascript framework on the block and we find ourselves with Zend_Form_SproutCore or some other dependency.

I've come up with a little prototype that's a PHP version of an ASP.NET implementation I did a couple months ago for a project I was working on.

The PHP version was surprisingly easier to implement, due to the simplicity of Zend_Form when compared to the bulldozer we-control-everything-and-rewrite-your-user-control-id's approach of ASP.NET forms.

Essentially, I've created a class with a simple form (1 lookup list (one-to-many for the data modelers out there) and a couple of simple textboxes).

While I think that it's crucial to decouple business rules from the actual form implementation, I think that Zend_Validate validators, as well as custom validators, are an excellent way of creating testable, declaritive validation rules that can be applied to form elements as you see fit. The other decoupling you'll find in this example is from the postback model, essentially allowing you to drop the same form into any part of a Zend Framework application and posting to an Ajax Controller service for validation purposes. What's nice about this is that no business rules are left on the client. I've used prototype for a little styling.

The finishing touch in all of this is that I can leverage the server-side validation routine for both the asynchronous and synchronous calls, so that postback and validation run through the same validation code, essentially providing a second interface with to the same form object.

I'm going to look into extending this example to provide not only one-to-one mapping and one-to-many mapping (lookup lists), but also many-to-one mapping (generating sub-forms dynamically and performing partial validation). Not sure exactly how to do that, so comments would be greatly appreciated!

Here's a quick demonstration.

and now for the code. The webservice bit is all contained in the IndexController for the sake of brevity. In a full blown application, you would likely have a Controller (or several controllers) that would offer different asynchronous entry points into your MVC framework.

class IndexController extends Zend_Controller_Action
{
	function indexAction()
	{
 
		$this->view->f = new RegistrationForm();
		$this->view->setMode = "setMode($('wsTab').childNodes[0]);";
 
		if ($this->view->f->isValid($_POST))
			return $this->render("FormSuccess");
 
		else if($this->_request->isPost())
		{
			$this->view->errorElements = $this->view->f->getMessages();
			$this->view->setMode = "setMode($('pbTab').childNodes[0]);";
		}
 
	}
 
	/**
	 * Ajax JSON call is made through this controller
	 *
	 */
	function asyncAction()
	{
		//prepare a JSON response
		$this->_helper->viewRenderer->setNoRender();
		$this->_helper->getHelper('layout')->disableLayout();
 
     	//Map the form from the client-side call
     	$myFormData = Zend_Json::decode($this->getRequest()->getParam("fs") , Zend_Json::TYPE_ARRAY);
     	$form = new RegistrationForm();
     	$form->isValid($myFormData);
 
     	//return the result
        $this->getResponse()->setHeader('Content-Type', 'application/json')
							   ->setBody(Zend_Json::encode($form->getMessages()));
 
	}
 
}
 

You'll notice that I've pulled out the form into its own class (RegistrationForm):

class RegistrationForm extends Zend_Form
{
 
    public function __construct()
    {
    	$this->setAttrib("id" , "frm");
 
    	$onetomany = new Zend_Form_Element_Select('sad');
    	$onetomany->setLabel('One to many:')
    			  ->setMultiOptions($this->getOneToMany())
    			  ->addValidator(new Onetomany());
 
        $usernameRequiredValidator = new Zend_Validate_NotEmpty();
        $usernameRequiredValidator->setMessage("Please enter a username.");
 
        $usernameStringLengthValidator = new Zend_Validate_StringLength(8,20);
        $usernameStringLengthValidator->setMessage("Username is too short! (8 character minimum)", Zend_Validate_StringLength::TOO_SHORT);
        $usernameStringLengthValidator->setMessage("Username is too long! (less than 20 characters)", Zend_Validate_StringLength::TOO_LONG);
 
    	$username = new Zend_Form_Element_Text('username');
        $username->setLabel('Username:')
        		 ->addValidator($usernameRequiredValidator)
        		 ->addValidator($usernameStringLengthValidator)
        		 ->setRequired(true);
 
    	$name = new Zend_Form_Element_Text('name');
        $name ->setLabel('Name:')
        		 ->addValidator('StringLength', true, array(4, 20))
        		 ->setRequired(true);    	
 
        $password = new Zend_Form_Element_Password('password');
        $password->setLabel('password:');
 
        $this->addElements(array(
        	$onetomany,
            $username,
            $name,
            $password
 
        ));
 
        $this->setDecorators(array(
        	'FormElements',
            'Fieldset',
            'Form'
 
        ));
 
        foreach ($this->getElements() as $element)
        {
        	$element->setDecorators(array(
                     array('ViewHelper', array('class' => 'formText')),
                     array('Label', array('class' => 'label')),
            		 array('HtmlTag', array('tag' => 'dd'))
                 ));
 
			$element->class = 'formText';
 
        }
    }
 
    private function getOneToMany()
	{
		$ar[" "] = "please select";
		$ar["car"] = "car";
		$ar["rollerBlade"] = "roller blades";
		return $ar;
 
	}
 
}
 

In my post about enterprise validation, I described a scenario where you would create custom validators that could be applied declaratively in C# using the Enterprise Library. The same thinking was applied here with the One To Many by creating a custom validator. This allows you to test the validation (and your business rules) without thinking about the form, the UI or even session:

class Onetomany extends Zend_Validate_Abstract
{
    const NOT_VALID  = 'stringLengthTooLong';
 
    /**
     * @var array
     */
    protected $_messageTemplates = array(
        self::NOT_VALID => "one to many was not valid choice",
 
    );
 
    /**
     * @var array
     */
    protected $_messageVariables = array(
        'not_valid' => '_not_valid',
 
    );
 
    protected $_not_valid;
 
    public function __construct()
    {
 
    }
 
    /**
     * Returns the min option
     *
     * @return integer
     */
    public function getNotValid()
    {
        return $this->_not_valid;
    }
 
    /**
     * Defined by Zend_Validate_Interface
     * @param  string $value
     * @return boolean
     */
    public function isValid($value)
    {
 
		// more business rules would go somewhere here...
        if ($value == " ")
            $this->_error(self::NOT_VALID);
 
        if (count($this->_messages)) {
            return false;
        } else {
            return true;
        }
    }
 
}
 

The last bit of magic is the Javascript. My weapon of choice (as mentioned above) is prototype, however I'm sure you could do the same thing with any other javascript framework:

Event.observe(window , "load" , function()
{
		<?= $this->setMode ?>
});
function attachWebServiceObserver()
{
		var url = "/index/async/";
		var f = JSON.stringify($('frm').serialize(true));
		new Ajax.Request(url , {
			method: 'post',
			parameters: 'fs=' + f,
			onComplete : doAjaxCall.bindAsEventListener(this)
			});
}
function attachPostBackObserver()
{
	$('frm').submit(); //this ID comes from the RegistrationForm class
}
 
function setMode(e)
{
	$$('.tab').each(function(emt) { emt.setStyle( {background : "" }) });
	e.parentNode.setStyle({background :"#FFFF99"});
 
	if (!FIRST_LOAD)
		clearErrors();
 
	if (e.parentNode.id =="wsTab")
	{
		Event.observe('bt', 'click', attachWebServiceObserver);
		Event.stopObserving('bt', 'click', attachPostBackObserver);
		$('bt').value = "Submit Asynchronously";
	}
 
	if (e.parentNode.id =="pbTab" )
	{
		Event.stopObserving('bt', 'click', attachWebServiceObserver);
		Event.observe('bt','click', attachPostBackObserver);
		$('bt').value = "Submit With Postback";
	}
	FIRST_LOAD = false;
 
}
function doAjaxCall(tr)
{
	clearErrors();
 
	if (formIsValid(tr.responseJSON))
		$('frm').submit();
 
	displayErrorMessages(tr.responseJSON);	
 
}
function clearErrors()
{
	$('dvPostbackErrors').update();
	$('dvPostbackErrors').hide();
 
	$$(".errormessage").each(function(e)
	{
		Element.remove(e);
	});
 
	$$("input.formText ").each(function(e)
	{
		e.setStyle({border : "1px solid #CCC"});
	});
	$$("select.formText ").each(function(e)
	{
		e.setStyle({border : "1px solid #CCC"});
	});
 
}
function formIsValid(errorJson)
{
 
	if(isNaN(errorJson))
		return false;
 
	return true;
}
function displayErrorMessages(errorJson)
{
 
	for (formElement in errorJson)
	{
 
		var elementObj = eval("errorJson."+formElement);
 
		for (error in elementObj)
			displayError(formElement , eval("errorJson."+formElement+"."+error));
 
	}
}
function displayError(emt , msg)
{
	var tpl = "<span class='errormessage' >"+msg+"</span>";
 
	markInvalidTextbox(emt);
 
	Element.insert(emt , {"after" : tpl });
}
function markInvalidTextbox(emt)
{
	$(emt).setStyle({border: "2px solid red"});
}
 

In the version that you can download, I include the JSON.stringify class (courtesy of Crawford) to serialize the form and send it the AsyncAction in my IndexController.

This architectural approach allows you to keep all the validation rules server-side, while allowing you to pick and choose when and how you postback. Because this example works with both postback and asynchronous calls, it's a little verbose.

Regardless, you can download the whole project and try it out for yourself.

Unlike most AJAX samples, this example doesn't require any server-side scripting or even a webserver.

Two notes about the video;
- It's not necessary to capture elements in Event.observe using $()
e.g. Event.observe('myHelloLink' ...) instead of Event.observe($('myHelloLink') ... );

- Instead of using innerHTML, you can also use .update("text changed on Load");

Enjoy!

The Purpose
As forms become more complex, there is greater incentive to minimize trips to the server. Furthermore, ASP.NET doesn't play nice with dynamically generated controls (something that occurs with any moderate AJAX development. The following is a way of utilizing the tools in the Microsoft ASP.NET framework without rewriting key components (for an example of this, look at the MonoRail project or the new Microsoft MVC framework).

In the Microsoft camp, usually you're encouraged to use validators that let act as decorators to existing ASP.NET textboxes and other form elements. To make matters more complicated, the Patterns and Practices group as well as the AJAX.NET group in Microsoft have competing components for dealing with client-side validation.

I propose a third method that employs a webservice and allows you to dynamically generate your validation through an asynchronous postback of your form to the server. I've been testing this approach and I've been pretty successful thus far:

On Using a Data Transfer Object (DTO)
A Data Transfer object is simply a container where you can store a collection of variables in an organized manner. A DTO doesn't have any behaviour, just public properties. For example, an Employee object might have the following properties:

	Employee employee = EmployeeRepository.GetNewEmployee();
	employee.HiredAt = DateTime.Now();
	employee.Position = "Sales Manager";
	employee.OfficeExtension = 4556;

To simplify things, I use Castleproject's ActiveRecord libraries to create a simple relationship between my database tables and my DTO's.

I've broken down the requests in terms of a linear timeline of events on the page.

Why Bother Mapping to a Data Transfer Object?
The Microsoft Enterprise Library enables you to decorate public properties (as well as methods) with validators. Furthermore, you create custom validators and include them in the same infrastructure that Microsoft provides for its own validators.

1) The page is rendered and delivered to the client's browser: for the most part, it's just a plain old aspx page. However, I've made certain minor modifications that help later on in the dynamic mapping of a DTO from the form back to the server:

A form element looks something like this:

 
	<ASP:TextBox id="tbEmployeePosition" dto="Employee" property="Position" runat="server" />
 

In my form, I've provided two attributes, dto and property, which can be used on in the web service to dynamically map the form elements back to the DTO for validation.

2) Use a fake button to post the form asynchronously to a webservice in your project: all the latest javascript frameworks (my personal favourite is Prototype) support form serialization through utility of helper methods (see $F() in prototype). The JSON object you want to send to the webservice might look like this:

 
{ "EmployeeForm" :
    [
	[ "id" : "aspnet_dynamic_form_tbEmployeePosition"]
	[ "value" : "Sales Manager"]
	[ "property" : "Position"]
	[ "dto" : "Employee"]
     ]
 
    [
	[ "id" : "aspnet_dynamic_form_tbEmployeeOfficeExtension"]
	[ "value" : "4556"]
	[ "property" : "OfficeExtension"]
	[ "dto" : "Employee"]
     ]
}
 

3) The Mapping Layer grabs a DTO from the Repository and maps the values using the Data from the JSON posted to the webservice: it's very easy to take this data and, using the PropertyInfo class and a bit of type checking, map these values to a DTO. Once their mapped, you can easily run Entlib Validation.

4) The ValidationManager validates the DTO, collects the EntLib Validation messages in a Hashtable: The Hashtable can have a key / value pair with the submitted form element's ID and the error message associated with the invalid element. Error messages are pulled from the MessageTemplate field in your validator's, whether you're adding attributes, or adding validation through your web.config.

5) The Hashtable is returned to the client: Microsoft's webservices don't support Hashtables natively, however you can get around this by creating an ArrayList containing string[] objects.

6) The values are inserted back onto the form: with a Hashtable containing element ID's and their respective messages, it becomes trivial to add these server-side messages to the client-side. In Prototype, it's a matter of Element.insert( responseJSON[i][0] , { "after" : "<span class='error'>"+responseJSON[i][1] + "</span>" }); where i corresponds with to the message in the list, 0 is the client's element ID and 1 is the message.

7) The Form is automatically submitted to the server if the form is valid: if responseJSON is empty, we simply fire the .click(); on the ASP.NET textbox as though the user did it himself. This means keeping track of the ASP.NET prefix which is added on all IDs that have the runat="server" directive.

The beauty of this approach is that it's highly extensible, you could serialize and post any part of your form if you needed to. Furthermore, the mapping that happens when the actual form controls are posted to the server would be nearly identical and the validation would be consolidated into one place. Lastly, you could provide the same error messages on server-side postback of the form (however it would be a little tricky to make them display as easily as it is with the web service.

I'll be providing a Zend sample of this in the week to come.

Here's a demo:

Implementing the code is really only one line once you have the back end web service configured:

 var demoAutocompleter = new MyAjaxAutocompleter('tbAutoCompleter', 'dvAutoCompleter', '/demo/html/Ajaxservice/index', {});

where 'tbAutoCompleter' corresponds to the textbox you wish to bind, 'dvAutoCompleter' is the control in question and '/demo/html/Ajaxservice/index' is the actual Web service giving you JSON data.

I'm still having a hard time POSTing to a Zend controller in a manner as elegant as you would find in ASP.NET's web services, however the code isn't really that bad. My AjaxServiceController looks like this:

class AjaxserviceController extends Zend_Controller_Action
{
	public function init()
	{
		$this->_helper->contextSwitch()
             ->addActionContext('index', 'json')
             ->initContext();
 
	}
 
	public function indexAction()
	{
 
       	$this->_helper->viewRenderer->setNoRender();
       	$this->_helper->getHelper('layout')->disableLayout();
 
       /* [Json response] */
		 $data = array("2008","3d","social","software","technology","tips",
"tools","toread","travel","tutorial",
"tutorials","tv","typography", "wiki","windows","wishlist","wordpress"
,"work","writing","youtube");
 
		 $responseData = $this->array_isearch($this->getRequest()->getParam('search') , $data);
 
       try {
 
           $responseDataJsonEncoded = Zend_Json::encode($responseData);
           $this->getResponse()->setHeader('Content-Type', 'application/json')
							   ->setBody($responseDataJsonEncoded);
 
       } catch(Zend_Json_Exception $e) {
           // handle and generate HTTP error code response, see below
       }
 
	}
 
    function array_isearch($str, $array) {
    	$returnArray = array();
        foreach($array as $v) {
            if(preg_match('/$str/i',$v))
            	$returnArray[] = $v;
 
        }
        return $returnArray;
    }
}
 

There's not much here, mostly just disabling the Zend Layout, specifying the content and doing the search. The $data array could easily be replaced with a data source (like a collection from Zend_Db).

Download Ajax Auto Completer Sample Zend Framework 1.5 project

The nice thing about web service AJAX controls is that they live independently of the application calling them, so you can essentially separate out your data layer in the same way that you would separate Zend_Db resources from a Zend_Controller.

Download Ajax Auto Completer Sample ASP.NET project

For example, take a look at line 301 of autocompleter.js:

 
  choicesToHtml : function(choices)
  {
    var output = "
<ul>";
        for (i=0; i< choices.length; i++)
            output = output + "
<li>" + choices[i] + "</li>
 
";
 
    return output + "</ul>
 
";
  }
 

Because you're actually pulling data from the web service, it would be easy to extend this example to provide a fully nested JSON object with images etc... as part of the auto-completer. I'll provide such an example with the Zend Framework and it's web service components at a later date, however being able to serialize a data structure like the one below would be perfect for an auto-completion web service.

 
 {
     "headerText": "SearchBox Header Text",
     "searchCollection": [
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
     ],
     "headerText": "SearchBox Footer Text"
 }
 

While I have excellent unix-based hosting, I unfortunately don't have an external IIS server that I can publish this out.

This has lead me to thinking about AJAX as a two-tier model.

This approach is very appealing from a development perspective since you can essentially develop a partial template, render it (using Zend_View if you're working in PHP) and send it down the pipe to the AJAX caller.

Usually there's an intermediate step on the client before display, whether it means parsing JSON / XML into XHTML or applying a fancy effect.

I think the latter approach will win out as a best practice since it lends itself to greater flexibility on the client side. With the push towards Service-Oriented Architectures, AJAX calls to webservices make more sense than simply relying on pre-built templates. Lastly, the jump from XML to XHTML isn't huge on a client-side and with rich javascript frameworks, parsing JSON and XML is a given.