[MANUAL] English:

- manual fixes

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@20176 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/en/module_specs/Zend_Application-AvailableResources-Multidb.xml

@@ -45,8 +45,8 @@ resources.multidb.db2.default = true
             <methodname>getDb()</methodname> returns an instance of a class that
             extends <classname>Zend_Db_Adapter_Abstract</classname>. If you have not
             set a default database, an exception will be thrown when this method
-            is called without specifying a parameter. 
-         </para>   
+            is called without specifying a parameter.
+         </para>
 
         <programlisting language="php"><![CDATA[
 $resource = $bootstrap->getPluginResource('multidb');
@@ -54,22 +54,24 @@ $db1 = $resource->getDb('db1');
 $db2 = $resource->getDb('db2');
 $defaultDb = $resource->getDb();
 ]]></programlisting>
-   </example>
-   
-       <example id="zend.application.available-resources.multidb.retrieveDefaultDb">
+    </example>
+
+    <example id="zend.application.available-resources.multidb.retrieveDefaultDb">
         <title>Retrieving the default database adapter</title>
 
         <para>
             Additionally, you can retrieve the default database adapter
             by using the method <methodname>getDefaultDb()</methodname>.
             If you have not set a default adapter, the first configured db
-            adapter will be returned. Unless you specify <constant>false</constant>
-            as first parameter, then <constant>null</constant>
+            adapter will be returned. Unless you specify <constant>FALSE</constant>
+            as first parameter, then <constant>NULL</constant>
             will be returned when no default database adapter was set.
-         </para>   
+         </para>
 
-        <para>Below is an example that assumes the Multidb resource plugin has been configured
-            with the INI sample above:</para>
+        <para>
+            Below is an example that assumes the Multidb resource plugin has been configured
+            with the <acronym>INI</acronym> sample above:
+        </para>
 
         <programlisting language="php"><![CDATA[
 $resource = $bootstrap->getPluginResource('multidb');
@@ -80,5 +82,4 @@ $db1 = $resource->getDefaultDb();
 $null = $resource->getDefaultDb(false); // null
 ]]></programlisting>
     </example>
-    
 </sect2>

documentation/manual/en/module_specs/Zend_Cache-Cache_Manager.xml

@@ -17,9 +17,9 @@
     </para>
 
     <para>
-        The basic operation of this component is as follows. The Cache Manager allows
-        users to setup "option templates", basically options for a set of named
-        caches. These can be set using the method <methodname>Zend_Cache_Manager::setCacheTemplate()</methodname>.
+        The basic operation of this component is as follows. The Cache Manager allows users to setup
+        "option templates", basically options for a set of named caches. These can be set using the
+        method <methodname>Zend_Cache_Manager::setCacheTemplate()</methodname>.
         These templates do not give rise to a cache until the user attempts to retrieve
         a named cache (associated with an existing option template) using the method
         <methodname>Zend_Cache_Manager::getCache()</methodname>.
@@ -192,10 +192,10 @@ $databaseCache = $manager->getCache('database');
         level as the conventional "public" directory of a Zend Framework application.
         The skeleton cache is actually a <constant>NULL</constant> cache, i.e. it contains no
         options. The remaining two caches are used to implement a default Static Page Cache
-        where static HTML/XML or even JSON may be written to static files in
-        /public. Control over a Static Page Cache is offered via
-        <classname>Zend_Controller_Action_Helper_Cache</classname>, though you may
-        alter the settings of this "page" the "tagcache" it uses to track tags using
+        where static <acronym>HTML</acronym>, <acronym>XML</acronym> or even <acronym>JSON</acronym>
+        may be written to static files in <filename>/public</filename>. Control over a Static Page
+        Cache is offered via <classname>Zend_Controller_Action_Helper_Cache</classname>, though you
+        may alter the settings of this "page" the "tagcache" it uses to track tags using
         <methodname>Zend_Cache_Manager::setTemplateOptions()</methodname> or even
         <methodname>Zend_Cache_Manager::setCacheTemplate()</methodname> if overloading
         all of their options.

documentation/manual/en/module_specs/Zend_Controller-Router-Route-Rest.xml

@@ -125,8 +125,8 @@ $front->getRouter()->addRoute('rest', $restRoute);
         <title>Zend_Rest_Route with Zend_Config_Ini</title>
 
     <para>
-        To use Zend_Rest_Route from an INI config file, use a route type
-        parameter and set the config options:
+        To use <classname>Zend_Rest_Route</classname> from an <acronym>INI</acronym> config file,
+        use a route type parameter and set the config options:
     </para>
 
     <programlisting language="ini"><![CDATA[
@@ -135,14 +135,18 @@ routes.rest.defaults.controller = object
 routes.rest.mod = project,user
 ]]></programlisting>
 
-    <para>The 'type' option designates the RESTful routing config type.
-    The 'defaults' option is used to specify custom default
-    module, controller, and/or actions for the route. All other options
-    in the config group are treated as RESTful module names, and their
-    values are RESTful controller names. The example config defines
-    Mod_ProjectController and Mod_UserController as RESTful controllers.</para>
+    <para>
+        The 'type' option designates the RESTful routing config type. The 'defaults' option is used
+        to specify custom default module, controller, and/or actions for the route. All other
+        options in the config group are treated as RESTful module names, and their values are
+        RESTful controller names. The example config defines
+        <classname>Mod_ProjectController</classname> and <classname>Mod_UserController</classname>
+        as RESTful controllers.
+    </para>
 
-    <para>Then use the addConfig() method of the Rewrite router object:</para>
+    <para>
+        Then use the <methodname>addConfig()</methodname> method of the Rewrite router object:
+    </para>
 
     <programlisting language="php"><![CDATA[
 $config = new Zend_Config_Ini('path/to/routes.ini');

documentation/manual/en/module_specs/Zend_Dojo-BuildLayers.xml

@@ -18,7 +18,7 @@
 
         <para>
             In order to create a build layer, you would traditionally create a
-            JavaScript file that has <code>dojo.require</code> statements for
+            JavaScript file that has <command>dojo.require</command> statements for
             each dependency, and optionally some additional code that might run
             when the script is loaded. As an example:
         </para>
@@ -64,9 +64,9 @@ $view->dojo()->registerModulePath('custom', '../custom/')
 
         <para>
             But since <classname>Zend_Dojo</classname> aggregates your various
-            <code>dojo.require</code> statements, how do you create your layer
+            <command>dojo.require</command> statements, how do you create your layer
             script? You could open each page and view the generated
-            <code>dojo.require</code> statements, and cut and paste them into a
+            <command>dojo.require</command> statements, and cut and paste them into a
             layer script file manually.
         </para>
 
@@ -211,12 +211,12 @@ $build->setLayerName("custom.main");
                 <title>Including onLoad events in the generated layer</title>
 
                 <para>
-                    <code>dojo.addOnLoad</code> is a useful utility for
+                    <command>dojo.addOnLoad</command> is a useful utility for
                     specifying actions that should trigger when the <acronym>DOM</acronym> has
                     finished loading. The <methodname>dojo()</methodname> view helper can
                     create these statements via its
                     <methodname>addOnLoad()</methodname> and
-                    <methodname>onLoadCapture*()</methodname> methods. In some
+                    <methodname>onLoadCapture()</methodname> methods. In some
                     cases, it makes sense to push these into your layer file
                     instead of rendering them via your view scripts.
                 </para>
@@ -253,7 +253,7 @@ $build->setConsumeOnLoad(true);
                     The <methodname>dojo()</methodname> view helper includes methods for
                     capturing arbitrary JavaScript to include in the
                     &lt;script&gt; tag containing the various
-                    <code>dojo.require</code> and <code>dojo.addOnLoad</code>
+                    <command>dojo.require</command> and <command>dojo.addOnLoad</command>
                     statements. This can be useful when creating default data
                     stores or globally scoped objects used throughout your
                     application.

documentation/manual/en/module_specs/Zend_Dojo-Data.xml

@@ -118,9 +118,9 @@ $data->addItems($someMoreItems);
             </para></listitem>
 
             <listitem><para>
-                Objects implementing the <code>Traversable</code> interface
-                ,which includes the interfaces <code>Iterator</code> and
-                <code>ArrayAccess</code>.
+                Objects implementing the <classname>Traversable</classname> interface
+                ,which includes the interfaces <classname>Iterator</classname> and
+                <classname>ArrayAccess</classname>.
             </para></listitem>
         </itemizedlist>
 
@@ -157,10 +157,10 @@ $data->fromJson($json);
 
         <para>
             Some Dojo components require additional metadata along with
-            the dojo.data payload. As an example, <code>dojox.grid.Grid</code>
+            the dojo.data payload. As an example, <command>dojox.grid.Grid</command>
             can pull data dynamically from a
-            <code>dojox.data.QueryReadStore</code>. For pagination to work
-            correctly, each return payload should contain a <code>numRows</code>
+            <command>dojox.data.QueryReadStore</command>. For pagination to work
+            correctly, each return payload should contain a <property>numRows</property>
             key with the total number of rows that could be returned by the
             query. With this data, the grid knows when to continue making small
             requests to the server for subsets of data and when to stop
@@ -209,8 +209,8 @@ $data->clearMetadata();
 
         <para>
             <classname>Zend_Dojo_Data</classname> implements the interfaces
-            <code>ArrayAccess</code>, <code>Iterator</code>, and
-            <code>Countable</code>. You can therefore use the data
+            <classname>ArrayAccess</classname>, <classname>Iterator</classname>, and
+            <classname>Countable</classname>. You can therefore use the data
             collection almost as if it were an array.
         </para>
 
@@ -289,7 +289,7 @@ $json = (string) $data; // cast to string == cast to JSON
                     <methodname>setItems($items)</methodname>: set multiple items at once,
                     overwriting any items that were previously set in the
                     object. <varname>$items</varname> should be an array or a
-                    <code>Traversable</code> object.
+                    <classname>Traversable</classname> object.
                 </para></listitem>
 
                 <listitem><para>
@@ -315,7 +315,7 @@ $json = (string) $data; // cast to string == cast to JSON
                     appending them to any current items. Will raise an exception
                     if any of the new items have an identifier matching an
                     identifier already in the collection. <varname>$items</varname>
-                    should be an array or a <code>Traversable</code> object.
+                    should be an array or a <classname>Traversable</classname> object.
                 </para></listitem>
 
                 <listitem><para>

documentation/manual/en/module_specs/Zend_Dojo-Form-Decorators.xml

@@ -12,7 +12,7 @@
     </para>
 
     <para>
-        All dijit decorators look for the <code>dijitParams</code> property of
+        All dijit decorators look for the <property>dijitParams</property> property of
         the given element being decorated, and push them as the
         <varname>$params</varname> array to the dijit view helper being used; these
         are then separated from any other properties so that no duplication of
@@ -25,10 +25,10 @@
         <para>
             Just like <link linkend="zend.form.standardDecorators.viewHelper">the
                 ViewHelper decorator</link>, DijitElement expects a
-            <code>helper</code> property in the element which it will then use
+            <property>helper</property> property in the element which it will then use
             as the view helper when rendering. Dijit parameters will typically
             be pulled directly from the element, but may also be passed in as
-            options via the <code>dijitParams</code> key (the value of that key
+            options via the <property>dijitParams</property> key (the value of that key
             should be an associative array of options).
         </para>
 
@@ -71,9 +71,9 @@ $element->setDecorators(array(
         </para>
 
         <para>
-            Since dijit.form.Form does not require any dijit parameters for
+            Since <command>dijit.form.Form</command> does not require any dijit parameters for
             configuration, the main difference is that the dijit form view
-            helper require that a DOM ID is passed to ensure that programmatic
+            helper require that a <acronym>DOM</acronym> ID is passed to ensure that programmatic
             dijit creation can work. The decorator ensures this, by passing the
             form name as the identifier.
         </para>
@@ -83,7 +83,7 @@ $element->setDecorators(array(
         <title>DijitContainer-based Decorators</title>
 
         <para>
-            The <code>DijitContainer</code> decorator is actually an abstract
+            The <classname>DijitContainer</classname> decorator is actually an abstract
             class from which a variety of other decorators derive. It offers
             the same functionality of <link
                 linkend="zend.dojo.form.decorators.dijitElement">DijitElement</link>,
@@ -97,7 +97,7 @@ $element->setDecorators(array(
 
         <para>
             The following is a list of decorators that inherit from
-            <code>DijitContainer</code>:
+            <classname>DijitContainer</classname>:
         </para>
 
         <itemizedlist>
@@ -138,6 +138,3 @@ $subForm->setDecorators(array(
         </example>
     </sect3>
 </sect2>
-<!--
-vim:se ts=4 sw=4 et:
--->

documentation/manual/en/module_specs/Zend_Dojo-Form-Elements.xml

@@ -49,7 +49,7 @@
     </itemizedlist>
 
     <para>
-        Dijit parameters are stored in the <code>dijitParams</code> public
+        Dijit parameters are stored in the <property>dijitParams</property> public
         property. Thus, you can dijit-enable an existing form element simply by
         setting this property on the element; you simply will not have the
         above accessors to facilitate manipulating the parameters.
@@ -79,7 +79,7 @@ $element->addDecorator('DijitElement')
 
     <para>
         A variant on DijitElement, DijitMulti, provides the functionality of
-        the <code>Multi</code> abstract form element, allowing the developer to
+        the <classname>Multi</classname> abstract form element, allowing the developer to
         specify 'multiOptions' -- typically select options or radio options.
     </para>
 
@@ -115,8 +115,8 @@ $element->addDecorator('DijitElement')
         </itemizedlist>
 
         <para>
-            Additionally, only the decorators <code>DijitElement</code> and
-            <code>DtDdWrapper</code> are utilized for Button elements.
+            Additionally, only the decorators <classname>DijitElement</classname> and
+            <classname>DtDdWrapper</classname> are utilized for Button elements.
         </para>
 
         <example id="zend.dojo.form.elements.button.example">
@@ -212,7 +212,7 @@ $form->addElement(
             <para>
                 ComboBoxes return the label values, and not the option values,
                 which can lead to a disconnect in expectations. For this reason,
-                ComboBoxes do not auto-register an <code>InArray</code>
+                ComboBoxes do not auto-register an <classname>InArray</classname>
                 validator (though FilteringSelects do).
             </para>
         </note>
@@ -281,11 +281,11 @@ $form->addElement(
 
         <para>
             By default, if no dojo.data store is registered with the element,
-            this element registers an <code>InArray</code> validator which
+            this element registers an <classname>InArray</classname> validator which
             validates against the array keys of registered options. You can
             disable this behavior by either calling
             <methodname>setRegisterInArrayValidator(false)</methodname>, or by passing a
-            <constant>FALSE</constant> value to the <code>registerInArrayValidator</code>
+            <constant>FALSE</constant> value to the <property>registerInArrayValidator</property>
             configuration key.
         </para>
 
@@ -336,8 +336,8 @@ $form->addElement(
         </example>
 
         <para>
-            The above examples could also utilize <code>FilteringSelect</code>
-            instead of <code>ComboBox</code>.
+            The above examples could also utilize <classname>FilteringSelect</classname>
+            instead of <classname>ComboBox</classname>.
         </para>
     </sect3>
 
@@ -1061,11 +1061,11 @@ $form->addElement(
         </para>
 
         <para>
-            By default, this element registers an <code>InArray</code> validator
+            By default, this element registers an <classname>InArray</classname> validator
             which validates against the array keys of registered options. You
             can disable this behavior by either calling
             <methodname>setRegisterInArrayValidator(false)</methodname>, or by passing a
-            <constant>FALSE</constant> value to the <code>registerInArrayValidator</code>
+            <constant>FALSE</constant> value to the <property>registerInArrayValidator</property>
             configuration key.
         </para>
 

documentation/manual/en/module_specs/Zend_Dojo-View-Helpers.xml

@@ -161,8 +161,8 @@ $view->addHelperPath('Zend/Dojo/View/Helper', 'Zend_Dojo_View_Helper');
 
         <para>
             All dijit layout elements have the
-            signature <code>string ($id = null, $content = '', array $params =
-                array(), array $attribs = array())</code>. In all caess, if you
+            signature <command>string ($id = null, $content = '', array $params =
+                array(), array $attribs = array())</command>. In all caess, if you
             pass no arguments, the helper object itself will be returned. This
             gives you access to the <methodname>captureStart()</methodname> and
             <methodname>captureEnd()</methodname> methods, which allow you to capture
@@ -327,8 +327,8 @@ $view->addHelperPath('Zend/Dojo/View/Helper', 'Zend_Dojo_View_Helper');
         <itemizedlist>
             <listitem>
                 <para>
-                    <code>captureStart($id, array $params = array(), array $attribs =
-                        array())</code>: begin capturing content to include in a container.
+                    <command>captureStart($id, array $params = array(), array $attribs =
+                        array())</command>: begin capturing content to include in a container.
                     <varname>$params</varname> refers to the dijit params to use with
                     the container, while <varname>$attribs</varname> refer to any
                     general HTML attributes to use.
@@ -411,9 +411,9 @@ echo $view->borderContainer()->captureEnd('masterLayout');
 
         <para>
             The following dijit form elements are available in Zend Framework.
-            Except where noted, all have the signature <code>string ($id,
+            Except where noted, all have the signature <command>string ($id,
                 $value = '', array $params = array(), array $attribs =
-                array())</code>.
+                array())</command>.
         </para>
 
         <itemizedlist>
@@ -477,7 +477,7 @@ echo $view->borderContainer()->captureEnd('masterLayout');
                     the list of available options, and it will still consider
                     it valid input. It accepts an optional fifth argument, an
                     associative array <varname>$options</varname>; if provided,
-                    ComboBox will be rendered as a <code>select</code>. Note
+                    ComboBox will be rendered as a <emphasis>select</emphasis>. Note
                     also that the <emphasis>label values</emphasis> of the
                     <varname>$options</varname> array will be returned in the form --
                     not the values themselves.
@@ -486,7 +486,7 @@ echo $view->borderContainer()->captureEnd('masterLayout');
                 <para>
                     Alternately, you may pass information regarding a dojo.data
                     datastore to use with the element. If provided, the
-                    ComboBox will be rendered as a text <code>input</code>, and
+                    ComboBox will be rendered as a text <emphasis>input</emphasis>, and
                     will pull its options via that datastore.
                 </para>
 
@@ -648,7 +648,7 @@ echo $view->dateTextBox(
                 <para>
                     <emphasis>Editor</emphasis>: dijit.Editor. Provides a
                     WYSIWYG editor via which users may create or edit content.
-                    <code>dijit.Editor</code> is a pluggable, extensible editor
+                    <command>dijit.Editor</command> is a pluggable, extensible editor
                     with a variety of parameters you can utilize for customization; see <ulink
                         url="http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/advanced-editing-and-display/editor-rich-text">the
                         dijit.Editor documentation</ulink> for more details.
@@ -791,7 +791,7 @@ echo $view->editor('foo');
                     <listitem><para>
                         <emphasis>attribs</emphasis> (optional): HTML
                         attributes to use with the rules/labels. This should
-                        follow the <code>params</code> option format and be an
+                        follow the <property>params</property> option format and be an
                         associative array with the keys 'container' and
                         'labels'.
                     </para></listitem>
@@ -939,7 +939,7 @@ echo $view->passwordTextBox(
                     RadioButton accepts an optional fifth argument,
                     <varname>$options</varname>, an associative array of value/label
                     pairs used as the radio options. You may also pass these as
-                    the <varname>$attribs</varname> key <code>options</code>.
+                    the <varname>$attribs</varname> key <property>options</property>.
                 </para>
 
                 <programlisting language="php"><![CDATA[
@@ -962,7 +962,7 @@ echo $view->radioButton(
                     <emphasis>SimpleTextarea</emphasis>: dijit.form.SimpleTextarea.
                     These act like normal textareas, but are styled using the
                     current dijit theme. You do not need to specify either the
-                    rows or columns attributes; use <code>ems</code> or
+                    rows or columns attributes; use <property>ems</property> or
                     percentages for the width and height, instead.
                 </para>
 
@@ -1127,20 +1127,20 @@ echo $view->validationTextBox(
             custom dijits, or using experimental dijits from Dojox. While Zend
             Framework cannot support every dijit directly, it does provide some
             rudimentary support for arbitrary dijit types via the
-            <code>CustomDijit</code> view helper.
+            <classname>CustomDijit</classname> view helper.
         </para>
 
         <para>
-            The <code>CustomDijit</code> view helper's <acronym>API</acronym> is exactly that of
-            any other dijit, with one major difference: the third "params"
+            The <classname>CustomDijit</classname> view helper's <acronym>API</acronym> is exactly
+            that of any other dijit, with one major difference: the third "params"
             argument <emphasis>must</emphasis> contain the attribute "dojotype".
             The value of this attribute should be the Dijit class you plan to
             use.
         </para>
 
         <para>
-            <code>CustomDijit</code> extends the base
-            <code>DijitContainer</code> view helper, which also allows it to
+            <classname>CustomDijit</classname> extends the base
+            <classname>DijitContainer</classname> view helper, which also allows it to
             capture content (using the
             <methodname>captureStart()</methodname>/<methodname>captureEnd()</methodname> pair of
             methods). <methodname>captureStart()</methodname> also expects that you pass the
@@ -1151,12 +1151,12 @@ echo $view->validationTextBox(
             <title>Using CustomDijit to render a dojox.layout.ContentPane</title>
 
             <para>
-                <code>dojox.layout.ContentPane</code> is a next-generation
-                iteration of <code>dijit.layout.ContentPane</code>, and provides
+                <command>dojox.layout.ContentPane</command> is a next-generation
+                iteration of <command>dijit.layout.ContentPane</command>, and provides
                 a superset of that class's capabilities. Until it's
                 functionality stabilizes, it will continue to live in Dojox.
                 However, if you want to use it in Zend Framework today, you can,
-                using the <code>CustomDijit</code> view helper.
+                using the <classname>CustomDijit</classname> view helper.
             </para>
 
             <para>
@@ -1195,10 +1195,10 @@ This is the content of the pane
 ]]></programlisting>
 
             <para>
-                You can also extend <code>CustomDijit</code> easily to create
+                You can also extend <classname>CustomDijit</classname> easily to create
                 support for your own custom dijits. As an example, if you
-                extended <code>dijit.layout.ContentPane</code> to create your
-                own <code>foo.ContentPane</code> class, you could create the
+                extended <command>dijit.layout.ContentPane</command> to create your
+                own <command>foo.ContentPane</command> class, you could create the
                 following helper to support it:
             </para>
 
@@ -1219,7 +1219,7 @@ class My_View_Helper_FooContentPane
 
             <para>
                 As long as your custom dijit follows the same basic <acronym>API</acronym> as
-                official dijits, using or extending <code>CustomDijit</code>
+                official dijits, using or extending <classname>CustomDijit</classname>
                 should work correctly.
             </para>
         </example>