The dojo() view helper is intended to simplify setting up the Dojo environment, including the following responsibilities: Specifying either a CDN or a local path to a Dojo install. Specifying paths to custom Dojo modules. Specifying dojo.require statements. Specifying dijit stylesheet themes to use. Specifying dojo.addOnLoad() events. The dojo() view helper implementation is an example of a placeholder implementation. The data set in it persists between view objects and may be directly echoed from your layout script. For this example, let's assume the developer will be using Dojo from a local path, will require several dijits, and will be utilizing the Tundra dijit theme. On many pages, the developer may not utilize Dojo at all. So, we will first focus on a view script where Dojo is needed and then on the layout script, where we will setup some of the Dojo environment and then render it. First, we need to tell our view object to use the Dojo view helper paths. This can be done in your bootstrap or an early-running plugin; simply grab your view object and execute the following: addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper'); ]]> Next, the view script. In this case, we're going to specify that we will be using a FilteringSelect -- which will consume a custom store based on QueryReadStore, which we'll call 'PairedStore' and store in our 'custom' module.

State: dojo()->enable() ->setDjConfigOption('parseOnLoad', true) ->registerModulePath('custom', '../custom/') ->requireModule('dijit.form.FilteringSelect') ->requireModule('custom.PairedStore'); ?> ]]> In our layout script, we'll then check to see if Dojo is enabled, and, if so, we'll do some more general configuration and assemble it: doctype() ?> headTitle() ?> headMeta() ?> headLink() ?> headStyle() ?> dojo()->isEnabled()){ $this->dojo()->setLocalPath('/js/dojo/dojo.js') ->addStyleSheetModule('dijit.themes.tundra'); echo $this->dojo(); } ?> headScript() ?> layout()->content ?> inlineScript() ?> ]]> At this point, you only need to ensure that your files are in the correct locations and that you've created the end point action for your FilteringSelect! Dojo allows both declarative and programmatic usage of many of its features. Declarative usage uses standard HTML elements with non-standard attributes that are parsed when the page is loaded. While this is a powerful and simple syntax to utilize, for many developers this can cause issues with page validation. Programmatic usage allows the developer to decorate existing elements by pulling them by ID or CSS selectors and passing them to the appropriate object constructors in Dojo. Because no non-standard HTML attributes are used, pages continue to validate. In practice, both use cases allow for graceful degradation when javascript is disabled or the various Dojo script resources are unreachable. To promote standards and document validation, Zend Framework uses programmatic usage by default; the various view helpers will generate javascript and push it to the dojo() view helper for inclusion when rendered. Developers using this technique may also wish to explore the option of writing their own programmatic decoration of the page. One benefit would be the ability to specify handlers for dijit events. To allow this, as well as the ability to use declarative syntax, there are a number of static methods available to set this behavior globally. To specify declarative usage, simply call the static setUseDeclarative() method: If you decide instead to use programmatic usage, call the static setUseProgrammatic() method: Finally, if you want to create your own programmatic rules, you should specify programmatic usage, but pass in the value '-1'; in this situation, no javascript for decorating any dijits used will be created. Dojo allows the creation of themes for its dijits (widgets). You may select one by passing in a module path: dojo()->addStylesheetModule('dijit.themes.tundra'); ]]> The module path is discovered by using the character '.' as a directory separator and using the last value in the list as the name of the CSS file in that theme directory to use; in the example above, Dojo will look for the theme in 'dijit/themes/tundra/tundra.css'. When using a theme, it is important to remember to pass the theme class to, at the least, a container surrounding any dijits you are using; the most common use case is to pass it in the body: ]]> By default, when you use a dojo.require statement, dojo will make a request back to the server to grab the appropriate javascript file. If you have many dijits in place, this results in many requests to the server -- which is not optimal. Dojo's answer to this is to provide the ability to create custom builds. Builds do several things: Groups required files into layers; a layer lumps all required files into a single JS file. (Hence the name of this section.) "Interns" non-javascript files used by dijits (typically, template files). These are also grouped in the same JS file as the layer. Passes the file through ShrinkSafe, which strips whitespace and comments, as well as shortens variable names. Some files can not be layered, but the build process will create a special release directory with the layer file and all other files. This allows you to have a slimmed-down distribution customized for your site or application needs. To use a layer, the dojo() view helper has a addLayer() method for adding paths to required layers: dojo()->addLayer('/js/foo/foo.js'); ]]> For more information on creating custom builds, please refer to the Dojo build documentation. The dojo() view helper always returns an instance of the dojo placeholder container. That container object has the following methods available: setView(Zend_View_Interface $view): set a view instance in the container. enable(): explicitly enable Dojo integration. disable(): disable Dojo integration. isEnabled(): determine whether or not Dojo integration is enabled. requireModule($module): setup a dojo.require statement. getModules(): determine what modules have been required. registerModulePath($module, $path): register a custom Dojo module path. getModulePaths(): get list of registered module paths. addLayer($path): add a layer (custom build) path to use. getLayers(): get a list of all registered layer paths (custom builds). removeLayer($path): remove the layer that matches $path from the list of registered layers (custom builds). setCdnBase($url): set the base URL for a CDN; typically, one of the Zend_Dojo::CDN_BASE_AOL or Zend_Dojo::CDN_BASE_GOOGLE, but it only needs to be the URL string prior to the version number. getCdnBase(): retrieve the base CDN url to utilize. setCdnVersion($version = null): set which version of Dojo to utilize from the CDN. getCdnVersion(): retrieve what version of Dojo from the CDN will be used. setCdnDojoPath($path): set the relative path to the dojo.js or dojo.xd.js file on a CDN; typically, one of the Zend_Dojo::CDN_DOJO_PATH_AOL or Zend_Dojo::CDN_DOJO_PATH_GOOGLE, but it only needs to be the path string following the version number. getCdnDojoPath(): retrieve the last path segment of the CDN url pointing to the dojo.js file. useCdn(): tell the container to utilize the CDN; implicitly enables integration. setLocalPath($path): tell the container the path to a local Dojo install (should be a path relative to the server, and contain the dojo.js file itself); implicitly enables integration. getLocalPath(): determine what local path to Dojo is being used. useLocalPath(): is the integration utilizing a Dojo local path? setDjConfig(array $config): set dojo/dijit configuration values (expects assoc array). setDjConfigOption($option, $value): set a single dojo/dijit configuration value. getDjConfig(): get all dojo/dijit configuration values. getDjConfigOption($option, $default = null): get a single dojo/dijit configuration value. addStylesheetModule($module): add a stylesheet based on a module theme. getStylesheetModules(): get stylesheets registered as module themes. addStylesheet($path): add a local stylesheet for use with Dojo. getStylesheets(): get local Dojo stylesheets. addOnLoad($spec, $function = null): add a lambda for dojo.onLoad to call. If one argument is passed, it is assumed to be either a function name or a javascript closure. If two arguments are passed, the first is assumed to be the name of an object instance variable and the second either a method name in that object or a closure to utilize with that object. prependOnLoad($spec, $function = null): exactly like addOnLoad(), excepts prepends to beginning of onLoad stack. getOnLoadActions(): retrieve all dojo.onLoad actions registered with the container. This will be an array of arrays. onLoadCaptureStart($obj = null): capture data to be used as a lambda for dojo.onLoad(). If $obj is provided, the captured JS code will be considered a closure to use with that Javascript object. onLoadCaptureEnd($obj = null): finish capturing data for use with dojo.onLoad(). javascriptCaptureStart(): capture arbitrary javascript to be included with Dojo JS (onLoad, require, etc. statements). javascriptCaptureEnd(): finish capturing javascript. __toString(): cast the container to a string; renders all HTML style and script elements.