Dojo View Helpers
Zend Framework provides the following Dojo-specific view helpers:
-
dojo(): setup the Dojo environment
for your page, including dojo configuration values, custom module paths, module
require statements, theme stylesheets, CDN usage, and more.
Example #1 Using Dojo View Helpers
To use Dojo view helpers, you will need to tell your view object
where to find them. You can do this by calling
addHelperPath():
$view->addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
Alternately, you can use Zend_Dojo's
enableView() method to do the work for you:
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.
Example #2 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.
span style="color: #808080; font-style: italic;">// setup data store for FilteringSelect ?>
"custom.PairedStore" jsId="stateStore"
url="/data/autocomplete/type/state/format/ajax"
requestMethod="get"// Input element: ?>
"state""dijit.form.FilteringSelect"
store="stateStore" pageSize="5"// setup required dojo elements:
'parseOnLoad''custom', '../custom/''dijit.form.FilteringSelect''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:
span style="color: #ff0000;">'/js/dojo/dojo.js')
->addStyleSheetModule('dijit.themes.tundra'"tundra"
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!
Note: 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.
Example #3 Specifying Declarative and Programmatic Dojo Usage
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.
Themes
Dojo allows the creation of themes for its dijits (widgets). You may
select one by passing in a module path:
span style="color: #ff0000;">'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:
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.
Dijit-Specific View Helpers
From the Dojo manual: "Dijit is a widget system layered on top of
dojo." Dijit includes a variety of layout and form widgets designed to
provide accessibility features, localization, and standardized (and
themeable) look-and-feel.
Zend Framework ships a variety of view helpers that allow you to render
and utilize dijits within your view scripts. There are three basic
types:
-
Layout Containers: these are designed to be
used within your view scripts or consumed by form decorators
for forms, sub forms, and display groups. They wrap the various
classes offerred in dijit.layout. Each dijit layout view helper
expects the following arguments:
-
$id: the container name or DOM ID.
-
$content: the content to wrap in the
layout container.
-
$params (optional): dijit-specific
parameters. Basically, any non-HTML attribute that can
be used to configure the dijit layout container.
-
$attribs (optional): any additional
HTML attributes that should be used to render the
container div. If the key 'id' is passed in this array, it will
be used for the form element DOM id, and
$id will be used for its name.
If you pass no arguments to a dijit layout view helper, the
helper itself will be returned. This allows you to capture
content, which is often an easier way to pass content to the
layout container. Examples of this functionality will be shown
later in this section.
-
Form Dijit: the dijit.form.Form dijit, while
not completely necessary for use with dijit form elements, will
ensure that if an attempt is made to submit a form that does
not validate against client-side validations, submission will
be halted and validation error messages raised. The form dijit
view helper expects the following arguments:
-
$id: the container name or DOM ID.
-
$attribs (optional): any additional
HTML attributes that should be used to render the
container div.
-
$content (optional): the content to wrap
in the form. If none is passed, an empty string will be
used.
The argument order varies from the other dijits in order to
keep compatibility with the standard form() view
helper.
-
Form Elements: these are designed to be
consumed with Zend_Form, but can be used
standalone within view scripts as well. Each dijit element view
helper expects the following arguments:
-
$id: the element name or DOM ID.
-
$value (optional): the current value of the element.
-
$params (optional): dijit-specific
parameters. Basically, any non-HTML attribute that can
be used to configure a dijit.
-
$attribs (optional): any additional
HTML attributes that should be used to render the dijit.
If the key 'id' is passed in this array, it will be used
for the form element DOM id, and $id
will be used for its name.
Some elements require more arguments; these will be noted with
the individual element helper descriptions.
In order to utilize these view helpers, you need to register the path
to the dojo view helpers with your view object.
Example #4 Registering the Dojo View Helper Prefix Path
$view->addHelperPath('Zend/Dojo/View/Helper', 'Zend_Dojo_View_Helper');
Dijit Layout Elements
The dijit.layout family of elements are for creating custom,
predictable layouts for your site. For any questions on general
usage, » read
more about them in the Dojo manual.
All dijit layout elements have the signature string ($id = null, $content = '',
array $params = array(), array $attribs = array()).
In all caess, if you pass no arguments, the helper object itself will be returned. This
gives you access to the captureStart() and
captureEnd() methods, which allow you to capture
content instead of passing it to the layout container.
|
|