In Zend_Db, after configuring your database, in order for arabic / persian / non-ascii characters to persist properly, you need to configure the character set:

 
// setup database
$db = Zend_Db::factory($config->db->adapter, $config_values);
// for Unicode support
$db->query("SET NAMES 'utf8'");
Zend_Db_Table::setDefaultAdapter($db);
 

In Doctrine, a similar declaration is needed to setup the right character set. These lines would be in the config.php file included in the sample project, or whenever you initialize your Doctrine_Manager:

 
$connection = Doctrine_Manager::connection(DB_PATH);
$connection->setCharset('UTF8');
 

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.

The equivalent Doctrine code is almost as elegant. Here's an excellent example of when objects abstract you from the nitty-gritty string parsing code that would be required to do time-stamping in a database:

 
$today = new Zend_Date();
$newPost = new Post();
 
$newPost->title = 'posting for ' . $today->get(Zend_Date::TIME_MEDIUM);
$newPost->createdAt = $today->get(Zend_Date::W3C);
$newPost->save();
 

Zend_Date::W3C returns a W3C compliant timestamp, which the Doctrine Model then passes to the underlying persistence layer.

Assuming that you had a UnitOfWork class handling your persistence, you could add createdAt to all of the YAML models, and have every record stamped with updatedAt and createdAt without changing any higher level code.

Why Bother With UpdatedAt and CreatedAt?

having these two columns in a table can save tremendous amounts of time sorting out concurrency issues. They also allow you to do some very primitive reporting on your data at no cost to adding complexity to the rest of your application.

My Doctrine Model was configured using a YAML file:

 
Post:
  tableName: post
  columns:
    id:
      primary: true
      autoincrement: true
      type: integer(4)
    createdAt: date
    title: string(255)
 

Then it's just a matter of running './doctrine rebuild-db' from the command line from the Doctrine directory and it create's the PHP classes and prepares the database columns.

Using Zend_Date, you can easily do date comparisons, generate different date formats, do complex date querying and so on without having to get into the string / number manipulations.

My solution stems from a layer between what the 37Signals would refer to as "the Model" and the Controller, namely a Repository which acts as a broker between a collection of Model objects and the Controller. By using a Repository and Zend_Form, the action of a Controller in an Application can go from being several hundred lines to a couple dozen.

In my last project, my fattest controller looked like this (NOTE: I've included the init() method for completeness):

 
	public function init()
	{
		$this->currentModelId = intval($this->_request->getParam("modelId"));
	}
	public function postsAction()
	{
 
		if (PostRepository::Exists($this->currentModelId))
		{
		//edit
			if ($this->_request->getParam("state") == "edit")
				$this->view->form = new forms_Post("edit", PostRepository::Find($this->currentModelId));						
 
		//delete
			elseif ($this->_request->getParam("state") == "delete")
			{
				PostRepository::Delete($this->currentModelId);
				$this->_forward('viewposts');
			}
		}
		else
		{
		    if (! $this->getRequest()->isPost())
			    $this->view->form = new forms_Post("create", PostRepository::NewPost());
 
			else
			    $this->view->form = new forms_Post("create", PostRepository::Find($this->_request->getParam("id")));
		}		
 
		//postback
		if ($this->getRequest()->isPost())
		{
		    if ($this->PostBack())
                       $this->_helper->Redirector->gotoUrl('/admin/viewposts');
		}
	}
	private function PostBack()
	{
 
		$post = array_merge($_POST, $_FILES);
		if ($this->view->form->isValid($post))
		{
			$this->view->form->persistData();
		    return true;
		}
		else
			$this->view->errorElements = $this->view->form->getMessages();
 
        return false;
	}
 

Because all my forms are attached in the same way and they use the same pattern, I can use the same PostBack() method on different forms.

To be honest, I don't like making calls to a repository statically, and in retrospect, I wouldn't recommend doing this again. This lead me to searching for a better Repository implementation in PHP.
As I was hunting through the the mighty Google, I found an article by Travis Swice in late 2007. While he's concerned with the 'getting' part of the pattern, I'm more interested in the 'setting' (persistence) part of the pattern. In Travis' example, he simple creates a 'new Repository();'. I have a problem with this, since its often times an over-abstraction of an early Domain.

In a simple application, or even during development, you don't want to take the complexities of a querying language out of SQL, into an object-relational mapping tool AND THEN into a Repository pattern! You're just bubbling up the problem. A Repository should simplify querying and persisting data by providing a relatively flat layer for your UI to make simple calls to. If you create an abstract base class called Repository, you can then collect these flat method calls into logical groupings.

In the example above, the PostRepository would inherit from a Repository class like the one below (along with all other Repositories) and it would handle the creation of Post objects as well as their object-relationship mappings to other models. While at first, "new Post();" seems like an equivalent call to "$postRepository->NewPost();", the latter can input default bits of content based on who is creating the Posting. While I know that I'm stretching the definition of a Repository, I do so because often times the pattern need not be completely implemented before its usefulness becomes apparent. As the project grows, you already have then necessary naming conventions in your codebase to implement a full blown domain. Think of it as picking a hiking trail and enjoying the mid-way summit instead of being stuck making your own road with a machete.

I'm still working through a full architecture, however I think with Doctrine, a bit of Reflection and the abstract base class below, I can come up with a half-way Repository pattern with a Unit of Work that will simplify persisting collections of objects with proper transactionality.

 
abstract class Repository {
 
	/**
	 * Unit of Work for each Repository Instantiated
	 *
	 * @var UnitOfWork
	 */
	protected $unitOfWork;
 
	public function __construct()
	{
		$this->unitOfWork = new UnitOfWork();
 
		//Doctrine Session initialization code here...
	}
 
	/**
	 * Add a Create object to the unit of work
	 *
	 * @param Doctrine_Record $model
	 */
	public function Create($model)
	{
		$this->unitOfWork->RegisterModelForCreate($model);
	}
 
	/**
	 * Add a Update object to the unit of work
	 *
	 * @param Doctrine_Record $model
	 */
	public function Update($model)
	{
		$this->unitOfWork->RegisterModelForUpdate($model);
 
	}
	/**
	 * Add a Delete object to the unit of work
	 *
	 * @param Doctrine_Record $model
	 */
	public function Delete($model)
	{
		$this->unitOfWork->RegisterModelForDelete($model);
 
	}
 
	public function Commit()
	{
		$this->unitOfWork->CommitAll();
	}
 
	private function clearUnitOfWork()
	{
		$this->unitOfWork->ClearAll();
	}
}
 

By putting the photos on Flickr, my client can keep posting photos and build a pool of images that other people can contribute to. From a development perspective, all I needed to do was leverage the Zend_Service_Flickr classes and write a simple wrapper.

The frontend page looks like this:

 
$randomPhotos = new RandomPhotosFromFlickr('YOUR_API_KEY');
$numberOfPhotos = 3;
 
echo "
<h2>Group Photos</h2>
 
";
foreach($randomPhotos->FromGroup($numberOfPhotos, "GROUP@ID") as $p)
	echo "<img src='".$p->Small->uri."' />";
 
echo "
<h2>User's Photos</h2>
 
";
foreach($randomPhotos->FromUser($numberOfPhotos, "user@yahoo.com") as $p)
	echo "<img src='".$p->Small->uri."' />";
 

In this example, $p is a Zend_Service_Flickr object, so you can pull any kind of data while letting the simple class I wrote handle the selection of random photos:

 
class RandomPhotosFromFlickr
{
	/**
	 * API key for Flickr
	 *
	 * @var string
	 */
	protected $apiKey;
 
	/**
	 * photoset used for retrieving random photos
	 *
	 * @var Zend_Service_Flickr_ResultSet
	 */
	protected $currentPhotoset;
 
	/**
	 * number of photos in the current photoset
	 *
	 * @var integer
	 */
	protected $totalPhotoCount;
 
	/**
	 * Class constructor
	 * We need your Flickr API Key
	 * Go to http://www.flickr.com/services/api/keys/apply/ to get one
	 * @param string $apiKey
	 */
	public function __construct($apiKey)
	{
		$this->apiKey = $apiKey;
 
	}
 
	/**
	 * Supply a username (a user's email address) and the number of photos you'd like returned
	 *
	 * @param integer $numberOfPhotos
	 * @param string $username
	 * @return Zend_Service_Flickr_ResultSet
	 */
	public function FromUser($numberOfPhotos, $username)
	{
		$flickr = new Zend_Service_Flickr($this->apiKey);
 
		$this->currentPhotoset = $flickr->userSearch($username);
		$this->totalPhotoCount = $this->currentPhotoset->totalResultsAvailable;
 
		$this->currentPhotoset = $flickr->userSearch($username, array('per_page' => $this->totalPhotoCount));
 
		return $this->getPhotosFromCurrentPhotoset($numberOfPhotos);
	}
 
	/**
	 * Supply a group ID and the number of photos you'd like returned
	 *
	 * @param integer $numberOfPhotos
	 * @param string $groupId
	 * @return Zend_Service_Flickr_ResultSet
	 */
	public function FromGroup($numberOfPhotos, $groupId)
	{
 
		$flickr = new Zend_Service_Flickr($this->apiKey);
 
		$this->currentPhotoset = $flickr->groupPoolGetPhotos($groupId);
		$this->totalPhotoCount = $this->currentPhotoset->totalResultsAvailable;
 
		$this->currentPhotoset = $flickr->groupPoolGetPhotos($groupId, array('per_page' => $this->totalPhotoCount));
 
		return $this->getPhotosFromCurrentPhotoset($numberOfPhotos);
 
	}
 
	/**
	 * Return an integer within the photo index range
	 *
	 * @return integer
	 */
	private function getRandomPhotoIndex()
	{
		return rand(0 , ($this->totalPhotoCount - 1));
	}
 
	/**
	 * Get a photo object from the Flickr Web Service
	 * Provide an indice from the current photo set
	 *
	 * @param integer $index
	 * @return Zend_Service_Flickr_Image
	 */
	private function getPhoto($index)
	{
		$this->currentPhotoset->seek($index);
		return $this->currentPhotoset->current();
	}
 
	/**
	 * using $this->currentPhotoset, grab a collection of random photos
	 *
	 * @param integer $numberOfPhotos
	 * @return Zend_Service_Flickr_ResultSet
	 */
	private function getPhotosFromCurrentPhotoset($numberOfPhotos)
	{
 
		// first collect up a list of IDs (making sure there are no duplicates
		$photoIds = array();
		while(count($photoIds) < $numberOfPhotos)
		{
			$id = $this->getRandomPhotoIndex();
 
			if (! in_array($id, $photoIds))
				$photoIds[] = $id;
		}
 
		$randomPhotos = array();
 
		// query the web service to grab the photo objects
		foreach ($photoIds as $id)
			$randomPhotos[] = $this->getPhoto($id);
 
		return $randomPhotos;
	}
 
}
 

you can download the full source if you'd like to try it yourself. Please note that I've omitted bundling my code with a copy of the Zend Framework.

Using Zend Framework's Zend_Service_Flickr

The Doctrine Documentation looks pretty solid and Ruben Savanne wrote a great article about integrating Doctrine into a Zend Framework project. I wholeheartedly agree with his statement that Zend_Db is a little too low level for 90% of tasks that application developers are aiming to accomplish. With a simple YAML configuration, Doctrine promises to generate the necessary classes and even your database schema. These two features are a must if you want to be able to model your database on the fly and run unit tests against a clean schema without writing a complex setup harness.

My only concern is the lack of any obvious enterprise support, regardless this library is worth looking at as an alternative to Zend_Db.

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.

Topics Covered:

• Zend Framework Folder Structure
• Zend_View and it's relationship to Zend_Controller
• Zend_Controller and the management of form postbacks
• Zend_Db Insert and Fetching rows
• using Zend_Layout to build headers and footers using the Zend MVC model

I've posted the first video here. Comments are much appreciated!

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.

Here's the full error:

Fatal error: Uncaught exception 'Zend_Controller_Dispatcher_Exception' with message 'Invalid controller specified (st)' in C:\wwwroot\library\Zend\Controller\Dispatcher\Standard.php:193 Stack trace: #0 C:\wwwroot\library\Zend\Controller\Front.php(911): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http)) #1 C:\wwwroot\index.php(34): Zend_Controller_Front->dispatch() #2 {main} thrown in C:\wwwroot\library\Zend\Controller\Dispatcher\Standard.php on line 193