# dojo() View Helper

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.

## dojo() View Helper Usage Example

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:

    $view->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.

    <?php // setup data store for FilteringSelect ?>
    <div dojoType="custom.PairedStore" jsId="stateStore"
        url="/data/autocomplete/type/state/format/ajax"
        requestMethod="get"></div>

    <?php // Input element: ?>
    State: <input id="state" dojoType="dijit.form.FilteringSelect"
        store="stateStore" pageSize="5" />

    <?php // setup required dojo elements:
    $this->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:

    <?php echo $this->doctype() ?>
    <html>
    <head>
        <?php echo $this->headTitle() ?>
        <?php echo $this->headMeta() ?>
        <?php echo $this->headLink() ?>
        <?php echo $this->headStyle() ?>
    <?php if ($this->dojo()->isEnabled()){
        $this->dojo()->setLocalPath('/js/dojo/dojo.js')
                     ->addStyleSheetModule('dijit.themes.tundra');
        echo $this->dojo();
       }
    ?>
        <?php echo $this->headScript() ?>
    </head>
    <body class="tundra">
        <?php echo $this->layout()->content ?>
        <?php echo $this->inlineScript() ?>
    </body>
    </html>

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!

## UTF-8 encoding used by default

By default, Zend Framework uses UTF-8 as its default encoding, and, specific to this case, `Zend_View` does as well. Character encoding can be set differently on the view object itself using the `setEncoding()` method (or the encoding instantiation parameter). However, since `Zend_View_Interface` does not define accessors for encoding, it's possible that if you are using a custom view implementation with the Dojo view helper, you will not have a `getEncoding()` method, which is what the view helper uses internally for determining the character set in which to encode.

If you do not want to utilize UTF-8 in such a situation, you will need to implement a `getEncoding()` method in your custom view implementation.

## Programmatic and Declarative Usage of Dojo

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.

### Specifying Declarative and Programmatic Dojo Usage

To specify declarative usage, simply call the static `setUseDeclarative()` method:

    Zend_Dojo_View_Helper_Dojo::setUseDeclarative();

If you decide instead to use programmatic usage, call the static `setUseProgrammatic()` method:

    Zend_Dojo_View_Helper_Dojo::setUseProgrammatic();

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.

    Zend_Dojo_View_Helper_Dojo::setUseProgrammatic(-1);

## Themes

Dojo allows the creation of themes for its dijits (widgets). You may select one by passing in a module path:

    $view->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:

    <body class="tundra">

## Using Layers (Custom Builds)

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:

    $view->dojo()->addLayer('/js/foo/foo.js');

For more information on creating custom builds, please refer to the Dojo build documentation.

## Methods Available

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 or dijit configuration values (expects assoc array).

- `setDjConfigOption($option, $value)`: set a single dojo or dijit configuration value.

- `getDjConfig()`: get all dojo or dijit configuration values.

- `getDjConfigOption($option, $default = null)`: get a single dojo or 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.