A Path Less Taken  
Breaking with convention in a very conventional fashion.

The first thing I discovered about the Zend Framework is that it is quite large. Each time I think that I have made progress in understanding a portion of the framework I run into something new or unexpected that slows me down again. My most recent road block occured while working on my home site (http://www.legendrefamily.org/). I was trying to use the Dojo JS framework to enhance the behavior of Zend_Form and I could not get the Dijit elements to work properly. I tried the blog post that I used previously to get the Dojo JS Framework working and it did not help address my problem. Specifically, because my Zend Framework application has a number of controllers I had an issue with code initializing Dojo in the layout.phtml file when the View did not use Dojo.

Since I was concerned that this might come up again I decided to set out the steps that I needed to take with any Zend Framework application in order to get the Dojo JS Framework to work properly. These steps are based on the blog post found at http://justanotherdeveloper.co.uk/2008/07/23/zend-framework-and-dojo/. I modified the solution presented to fit my understanding of the Zend Framework. As my understanding of the framework grows I may find a more appropriate way to accomplish this, but for now this approach works and is sufficient for my needs.

The first step is to override the init function for every controller that needs the Dojo library. I do this using the following code:

public function init () {
     Zend_Dojo::enableView ($this->view) ;
     $this->view->meDojo = true ;
}

The first line enables the Zend_Dojo View Helper for the view associated with the controller. The second line is a variable that I create and assign to the view for use in the layout.phtml file.

Next I edited the layout.phtml file to include the following lines in the header.

if (isset ($this->meDojo)) {
     $this->headLink ()->appendStylesheet ('../js/dojo-release-1.2.2-src/dijit/themes/tundra/tundra.css') ;
     $this->dojo ()->setLocalPath ('../js/dojo-release-1.2.2-src/dojo/dojo.js') ;
     print $this->dojo () ;
}

I check to see if the variable meDojo is present in the view. If it is then I add the style sheet to the header, set the path to the Dojo JS Framework and call the dojo method of the view to output the JS required to initialize Dojo. In the example from the link above the author suggests using the isEnabled method rather than the approach I took. After some checking I was able to find the isEnabled method in the Zend_Dojo_View_Helper_Dojo_Container class. The problem that I had is I did not know how to reference this class and method when the Dojo JS Framework was not present. The meDojo property of the view is my simple workaround to manage conditional rendering of Dojo JS. If in the future I determine the proper way to leverage isEnabled in this context then I will likely alter my approach to take advantage of functionality built into the Zend Framework.

Another problem that I encountered was the Dojo Dijit rendering. I was testing the DateTextBox Dojo Form Element and it was not rendering as expected. My first assumption was the Blueprint CSS Framework style sheets were changing the behavior of the Dijit Form Element. This did not track since the Blueprint CSS files were included first in the rendered page. I also noticed that when I included both the tundra.css and dojo.css files in my document that my page view changed and my resulting control did not match the reference page I built of Dojo JS Framework without the Zend Framework.

After a careful review I finally figured out that my reference page had the tundra class applied to the body tag. This was not the case for my Zend Framework page. I changed the body tag in the layout.phtml page to include the class tundra and all the Dojo controls rendered to match my reference page.

That was all it took. I hope that if you are having the same problem this post can help save you the pain I experienced.

Peace.