[DOCUMENTATION] English:

 - manual fixes

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

documentation/manual/en/module_specs/Zend_Controller-FrontController.xml

@@ -108,7 +108,7 @@ $front = Zend_Controller_Front::getInstance();
                 where to look for <link
                     linkend="zend.controller.action">action controller</link>
                 class files. It accepts either a single path or an associative
-                array of module/path pairs.
+                array of module and path pairs.
             </para>
 
             <para>
@@ -134,7 +134,7 @@ $front->addControllerDirectory('../modules/foo/controllers', 'foo');
                 <para>
                     If you use <methodname>addControllerDirectory()</methodname> without a
                     module name, it will set the directory for the
-                    <code>default</code> module -- overwriting it if it already
+                    <emphasis>default</emphasis> module -- overwriting it if it already
                     exists.
                 </para>
             </note>
@@ -142,7 +142,7 @@ $front->addControllerDirectory('../modules/foo/controllers', 'foo');
             <para>
                 You can get the current settings for the controller directory
                 using <methodname>getControllerDirectory()</methodname>; this will return an
-                array of module/directory pairs.
+                array of module and directory pairs.
             </para>
         </sect3>
 
@@ -159,8 +159,8 @@ $front->addControllerDirectory('../modules/foo/controllers', 'foo');
             <para>
                 Each module should be in its own directory and mirror the
                 directory structure of the default module -- i.e., it should
-                have a "controllers" subdirectory at the minimum, and typically
-                a "views" subdirectory and other application subdirectories.
+                have a <filename>/controllers/</filename> subdirectory at the minimum, and typically
+                a <filename>/views/</filename> subdirectory and other application subdirectories.
             </para>
 
             <para>
@@ -195,7 +195,7 @@ $front->addControllerDirectory('../modules/foo/controllers', 'foo');
                 If no request or response object are passed in,
                 <methodname>dispatch()</methodname> will check for previously registered
                 objects and use those or instantiate default versions to use in
-                its process (in both cases, the HTTP flavor will be used as the
+                its process (in both cases, the <acronym>HTTP</acronym> flavor will be used as the
                 default).
             </para>
 
@@ -232,7 +232,7 @@ $front->addControllerDirectory('../modules/foo/controllers', 'foo');
             <title>run()</title>
 
             <para>
-                <classname>Zend_Controller_Front::run($path)</classname> is a static
+                <methodname>Zend_Controller_Front::run($path)</methodname> is a static
                 method taking simply a path to a directory containing
                 controllers. It fetches a front controller instance (via
                 <link
@@ -282,9 +282,7 @@ Zend_Controller_Front::run('../application/controllers');
                     <methodname>(set|get)DefaultControllerName()</methodname> let you
                     specify a different name to use for the default controller
                     ('index' is used otherwise) and retrieve the current value.
-                    They proxy to <link
-                        linkend="zend.controller.dispatcher">the
-                        dispatcher</link>.
+                    They proxy to <link linkend="zend.controller.dispatcher">the dispatcher</link>.
                 </para>
             </listitem>
 
@@ -293,8 +291,7 @@ Zend_Controller_Front::run('../application/controllers');
                     <methodname>(set|get)DefaultAction()</methodname> let you specify a
                     different name to use for the default action ('index' is
                     used otherwise) and retrieve the current value. They proxy
-                    to <link linkend="zend.controller.dispatcher">the
-                        dispatcher</link>.
+                    to <link linkend="zend.controller.dispatcher">the dispatcher</link>.
                 </para>
             </listitem>
 
@@ -367,8 +364,8 @@ Zend_Controller_Front::run('../application/controllers');
 
             <listitem>
                 <para>
-                    <methodname>registerPlugin(Zend_Controller_Plugin_Abstract $plugin, $stackIndex =
-                        null)</methodname> allows you to register <link
+                    <methodname>registerPlugin(Zend_Controller_Plugin_Abstract $plugin,
+                        $stackIndex = null)</methodname> allows you to register <link
                         linkend="zend.controller.plugins">plugin objects</link>.
                     By setting the optional <varname>$stackIndex</varname>, you can
                     control the order in which plugins will execute.
@@ -396,8 +393,8 @@ Zend_Controller_Front::run('../application/controllers');
                 </para>
 
                 <para>
-                    For more information, read <xref
-                        linkend="zend.controller.exceptions" />.
+                    For more information, read <link linkend="zend.controller.exceptions">MVC
+                        Exceptions</link>.
                 </para>
             </listitem>
 
@@ -409,7 +406,7 @@ Zend_Controller_Front::run('../application/controllers');
                     response should be automatically emitted
                     (<constant>FALSE</constant>). By default, the response is
                     automatically emitted (by calling
-                    <classname>Zend_Controller_Response_Abstract::sendResponse()</classname>);
+                    <methodname>Zend_Controller_Response_Abstract::sendResponse()</methodname>);
                     turning on <methodname>returnResponse()</methodname> will override this
                     behaviour.
                 </para>
@@ -494,7 +491,8 @@ Zend_Controller_Front::run('../application/controllers');
                 </para>
 
                 <para>
-                    See <xref linkend="zend.controller.exceptions.internal" />
+                    See <link linkend="zend.controller.exceptions.internal">MVC Exceptions
+                        You May Encounter</link>
                     for more detailed information on using this setting.
                 </para>
             </listitem>
@@ -554,7 +552,7 @@ class My_Controller_Front extends Zend_Controller_Front
         <para>
             Overriding the <methodname>getInstance()</methodname> method ensures that
             subsequent calls to
-            <classname>Zend_Controller_Front::getInstance()</classname> will return an
+            <methodname>Zend_Controller_Front::getInstance()</methodname> will return an
             instance of your new subclass instead of a
             <classname>Zend_Controller_Front</classname> instance -- this is particularly
             useful for some of the alternate routers and view helpers.

documentation/manual/en/module_specs/Zend_Controller-Migration.xml

@@ -4,8 +4,8 @@
     <title>Migrating from Previous Versions</title>
 
     <para>
-        The API of the MVC components has changed over time. If you started
-        using Zend Framework in an early version, follow the guidelines below to
+        The <acronym>API</acronym> of the <acronym>MVC</acronym> components has changed over time.
+        If you started using Zend Framework in an early version, follow the guidelines below to
         migrate your scripts to use the new architecture.
     </para>
 
@@ -42,12 +42,14 @@
             </para>
 
             <itemizedlist>
-                <listitem><para>
-                    <methodname>formatModuleName()</methodname>: should be used to take a raw
-                controller name, such as one that would be packaged inside a request
-                object, and reformat it to a proper class name that a class extending
-                <classname>Zend_Controller_Action</classname> would use
-                </para></listitem>
+                <listitem>
+                    <para>
+                        <methodname>formatModuleName()</methodname>: should be used to take a raw
+                        controller name, such as one that would be packaged inside a request
+                        object, and reformat it to a proper class name that a class extending
+                        <classname>Zend_Controller_Action</classname> would use
+                    </para>
+                </listitem>
             </itemizedlist>
         </sect3>
     </sect2>
@@ -97,17 +99,17 @@
         </para>
 
         <para>
-            When writing URLs, the documented way to write camelCased action
+            When writing <acronym>URL</acronym>s, the documented way to write camelCased action
             names is to use a word separator; these are '.' or '-' by default,
             but may be configured in the dispatcher. The dispatcher internally
             lowercases the action name, and uses these word separators to
-            re-assemble the action method using camelCasing. However, because PHP
+            re-assemble the action method using camelCasing. However, because <acronym>PHP</acronym>
             functions are not case sensitive, you <emphasis>could</emphasis>
-            still write URLs using camelCasing, and the dispatcher would resolve
+            still write <acronym>URL</acronym>s using camelCasing, and the dispatcher would resolve
             these to the same location. For example, 'camel-cased' would become
             'camelCasedAction' by the dispatcher, whereas 'camelCased' would
             become 'camelcasedAction'; however, due to the case insensitivity of
-            PHP, both will execute the same method.
+            <acronym>PHP</acronym>, both will execute the same method.
         </para>
 
         <para>
@@ -118,8 +120,8 @@
             normalization ensures that the scripts can be found. However, if the
             action 'camelCased' is called and actually resolves, the word
             separator is no longer present, and the ViewRenderer attempts to
-            resolve to a different location -- 'camelcased.phtml' instead of
-            'camel-cased.phtml'.
+            resolve to a different location -- <filename>camelcased.phtml</filename> instead of
+            <filename>camel-cased.phtml</filename>.
         </para>
 
         <para>
@@ -140,12 +142,14 @@
         </para>
 
         <itemizedlist>
-            <listitem><para>
+            <listitem>
+                <para>
                     Best option: rename your view scripts. Pros: forward
                     compatibility. Cons: if you have many view scripts that
                     relied on the former, unintended behavior, you will have a
                     lot of renaming to do.
-            </para></listitem>
+                </para>
+            </listitem>
 
             <listitem>
                 <para>
@@ -186,7 +190,7 @@ $inflector->setFilterRule(':action', array(
                 <para>
                     Least desirable option: You can force the dispatcher to
                     dispatch camelCased action names with a new front controller
-                    flag, 'useCaseSensitiveActions':
+                    flag, <property>useCaseSensitiveActions</property>:
                 </para>
 
                 <programlisting language="php"><![CDATA[
@@ -226,11 +230,11 @@ $front->setParam('useCaseSensitiveActions', true);
         </para>
 
         <para>
-            The <emphasis>ErrorHandler</emphasis> plugin runs during
+            The <classname>ErrorHandler</classname> plugin runs during
             <methodname>postDispatch()</methodname> checking for exceptions, and forwarding
             to a specified error handler controller. You should include such a
             controller in your application. You may disable it by setting the
-            front controller parameter <code>noErrorHandler</code>:
+            front controller parameter <property>noErrorHandler</property>:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -238,18 +242,18 @@ $front->setParam('noErrorHandler', true);
 ]]></programlisting>
 
         <para>
-            The <emphasis>ViewRenderer</emphasis> action helper automates view injection
+            The <classname>ViewRenderer</classname> action helper automates view injection
             into action controllers as well as autorendering of view scripts
             based on the current action. The primary issue you may encounter is
             if you have actions that do not render view scripts and neither
-            forward or redirect, as the <emphasis>ViewRenderer</emphasis> will attempt
+            forward or redirect, as the <classname>ViewRenderer</classname> will attempt
             to render a view script based on the action name.
         </para>
 
         <para>
             There are several strategies you can take to update your code. In
             the short term, you can globally disable the
-            <emphasis>ViewRenderer</emphasis> in your front controller bootstrap prior
+            <classname>ViewRenderer</classname> in your front controller bootstrap prior
             to dispatching:
         </para>
 
@@ -264,7 +268,7 @@ $front->setParam('noViewRenderer', true);
         </para>
 
         <para>
-            When you're ready to start using the <emphasis>ViewRenderer</emphasis>
+            When you're ready to start using the <classname>ViewRenderer</classname>
             functionality, there are several things to look for in your
             controller code. First, look at your action methods (the methods
             ending in 'Action'), and determine what each is doing. If none of
@@ -273,16 +277,16 @@ $front->setParam('noViewRenderer', true);
 
         <itemizedlist>
             <listitem>
-                <para>Calls to <methodname>$this-&gt;render()</methodname></para>
+                <para>Calls to <methodname>$this->render()</methodname></para>
             </listitem>
             <listitem>
-                <para>Calls to <methodname>$this-&gt;_forward()</methodname></para>
+                <para>Calls to <methodname>$this->_forward()</methodname></para>
             </listitem>
             <listitem>
-                <para>Calls to <methodname>$this-&gt;_redirect()</methodname></para>
+                <para>Calls to <methodname>$this->_redirect()</methodname></para>
             </listitem>
             <listitem>
-                <para>Calls to the <emphasis>Redirector</emphasis> action helper</para>
+                <para>Calls to the <classname>Redirector</classname> action helper</para>
             </listitem>
         </itemizedlist>
 
@@ -335,7 +339,7 @@ public function preDispatch()
                     If you're calling <methodname>render()</methodname> with arguments, and
                     not doing any processing afterwards or rendering multiple
                     view scripts, you can change these calls to read
-                    <methodname>$this-&gt;_helper-&gt;viewRenderer()</methodname>.
+                    <methodname>$this->_helper->viewRenderer()</methodname>.
                 </para>
             </listitem>
         </itemizedlist>
@@ -344,7 +348,7 @@ public function preDispatch()
             If you're not using the conventional modular directory structure,
             there are a variety of methods for setting the view base path and
             script path specifications so that you can make use of the
-            <emphasis>ViewRenderer</emphasis>. Please read the <link
+            <classname>ViewRenderer</classname>. Please read the <link
                 linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer
                 documentation</link> for information on these methods.
         </para>
@@ -352,7 +356,7 @@ public function preDispatch()
         <para>
             If you're using a view object from the registry, or customizing your
             view object, or using a different view implementation, you'll want
-            to inject the <emphasis>ViewRenderer</emphasis> with this object. This can
+            to inject the <classname>ViewRenderer</classname> with this object. This can
             be done easily at any time.
         </para>
 
@@ -383,18 +387,18 @@ $viewRenderer->setView($view);
         </itemizedlist>
 
         <para>
-            There are many ways to modify the <emphasis>ViewRenderer</emphasis>,
+            There are many ways to modify the <classname>ViewRenderer</classname>,
             including setting a different view script to render, specifying
             replacements for all replaceable elements of a view script path
             (including the suffix), choosing a response named segment to
             utilize, and more. If you aren't using the conventional modular
             directory structure, you can even associate different path
-            specifications with the <emphasis>ViewRenderer</emphasis>.
+            specifications with the <classname>ViewRenderer</classname>.
         </para>
 
         <para>
             We encourage you to adapt your code to use the
-            <emphasis>ErrorHandler</emphasis> and <emphasis>ViewRenderer</emphasis> as they are
+            <classname>ErrorHandler</classname> and <classname>ViewRenderer</classname> as they are
             now core functionality.
         </para>
     </sect2>
@@ -446,7 +450,7 @@ $viewRenderer->setView($view);
         <title>Migrating from 0.6.0 to 0.8.0 or Newer</title>
 
         <para>
-            Per previous changes, the most basic usage of the MVC components
+            Per previous changes, the most basic usage of the <acronym>MVC</acronym> components
             remains the same:
         </para>
 
@@ -483,7 +487,7 @@ Zend_Controller_Front::run('/path/to/controllers');
                     A new route class for use with the rewrite router was
                     introduced,
                     <classname>Zend_Controller_Router_Route_Module</classname>; it covers
-                    the default route used by the MVC, and has support for <link
+                    the default route used by the <acronym>MVC</acronym>, and has support for <link
                         linkend="zend.controller.modular">controller
                         modules</link>.
                 </para>
@@ -505,7 +509,7 @@ Zend_Controller_Front::run('/path/to/controllers');
 
             <listitem>
                 <para>
-                    <classname>Zend_Controller_Action::_forward()</classname>'s arguments
+                    <methodname>Zend_Controller_Action::_forward()</methodname>'s arguments
                     have changed. The signature is now:
                 </para>
 
@@ -534,7 +538,7 @@ final protected function _forward($action,
         <title>Migrating from 0.2.0 or before to 0.6.0</title>
 
         <para>
-            The most basic usage of the MVC components has not changed; you can
+            The most basic usage of the <acronym>MVC</acronym> components has not changed; you can
             still do each of the following:
         </para>
 
@@ -562,7 +566,8 @@ $ctrl->dispatch();
         <para>
             We encourage use of the Response object to aggregate content and
             headers. This will allow for more flexible output format switching
-            (for instance, JSON or XML instead of XHTML) in your applications.
+            (for instance, <acronym>JSON</acronym> or <acronym>XML</acronym> instead of
+            <acronym>XHTML</acronym>) in your applications.
             By default, <methodname>dispatch()</methodname> will render the response, sending both
             headers and rendering any content. You may also have the front
             controller return the response using <methodname>returnResponse()</methodname>,
@@ -572,7 +577,7 @@ $ctrl->dispatch();
         </para>
 
         <para>
-            There are many additional features that extend the existing API,
+            There are many additional features that extend the existing <acronym>API</acronym>,
             and these are noted in the documentation.
         </para>
 
@@ -584,7 +589,7 @@ $ctrl->dispatch();
         <itemizedlist>
             <listitem>
                 <para>
-                    <classname>Zend_Controller_Front::dispatch()</classname> by default
+                    <methodname>Zend_Controller_Front::dispatch()</methodname> by default
                     traps exceptions in the response object, and does not render
                     them, in order to prevent sensitive system information from
                     being rendered. You can override this in several ways:
@@ -621,73 +626,91 @@ echo $response;
                 </itemizedlist>
             </listitem>
 
-            <listitem><para>
-                <classname>Zend_Controller_Dispatcher_Interface::dispatch()</classname>
-                now accepts and returns a <xref linkend="zend.controller.request" />
-                object instead of a dispatcher token.
-            </para></listitem>
+            <listitem>
+                <para>
+                    <methodname>Zend_Controller_Dispatcher_Interface::dispatch()</methodname>
+                    now accepts and returns a <link linkend="zend.controller.request">The
+                    Request Object</link> instead of a dispatcher token.
+                </para>
+            </listitem>
 
-            <listitem><para>
-                <classname>Zend_Controller_Router_Interface::route()</classname>
-                now accepts and returns a <xref linkend="zend.controller.request" />
-                object instead of a dispatcher token.
-            </para></listitem>
+            <listitem>
+                <para>
+                    <methodname>Zend_Controller_Router_Interface::route()</methodname>
+                    now accepts and returns a <link linkend="zend.controller.request">The
+                    Request Object</link> instead of a dispatcher token.
+                </para>
+            </listitem>
 
             <listitem>
                 <para><classname>Zend_Controller_Action</classname> changes include:</para>
 
                 <itemizedlist>
-                    <listitem><para>
-                        The constructor now accepts exactly three arguments,
-                        <classname>Zend_Controller_Request_Abstract $request</classname>,
-                        <classname>Zend_Controller_Response_Abstract $response</classname>,
-                        and <command>array $params (optional)</command>.
-                        <classname>Zend_Controller_Action::__construct()</classname> uses
-                        these to set the request, response, and invokeArgs
-                        properties of the object, and if overriding the
-                        constructor, you should do so as well. Better yet, use
-                        the <methodname>init()</methodname> method to do any instance
-                        configuration, as this method is called as the final
-                        action of the constructor.
-                    </para></listitem>
-
-                    <listitem><para>
-                        <methodname>run()</methodname> is no longer defined as final, but is
-                        also no longer used by the front controller; its sole
-                        purpose is for using the class as a page controller. It
-                        now takes two optional arguments, a
-                        <classname>Zend_Controller_Request_Abstract $request</classname>
-                        and a <classname>Zend_Controller_Response_Abstract $response</classname>.
-                    </para></listitem>
-
-                    <listitem><para>
-                        <methodname>indexAction()</methodname> no longer needs to be
-                        defined, but is encouraged as the default action. This
-                        allows using the RewriteRouter and action controllers to
-                        specify different default action methods.
-                    </para></listitem>
-
-                    <listitem><para>
-                        <methodname>__call()</methodname> should be overridden to handle any
-                        undefined actions automatically.
-                    </para></listitem>
-
-                    <listitem><para>
-                        <methodname>_redirect()</methodname> now takes an optional second
-                        argument, the HTTP code to return with the redirect, and
-                        an optional third argument, <varname>$prependBase</varname>,
-                        that can indicate that the base URL registered with the
-                        request object should be prepended to the url specified.
-                    </para></listitem>
+                    <listitem>
+                        <para>
+                            The constructor now accepts exactly three arguments,
+                            <classname>Zend_Controller_Request_Abstract</classname>
+                            <varname>$request</varname>,
+                            <classname>Zend_Controller_Response_Abstract</classname>
+                            <varname>$response</varname>,
+                            and <type>Array</type> <varname>$params</varname> (optional).
+                            <methodname>Zend_Controller_Action::__construct()</methodname> uses
+                            these to set the request, response, and invokeArgs
+                            properties of the object, and if overriding the
+                            constructor, you should do so as well. Better yet, use
+                            the <methodname>init()</methodname> method to do any instance
+                            configuration, as this method is called as the final
+                            action of the constructor.
+                        </para>
+                    </listitem>
 
                     <listitem>
                         <para>
-                            The <varname>$_action</varname> property is no longer set. This property was a
-                            <classname>Zend_Controller_Dispatcher_Token</classname>,
+                            <methodname>run()</methodname> is no longer defined as final, but is
+                            also no longer used by the front controller; its sole
+                            purpose is for using the class as a page controller. It
+                            now takes two optional arguments, a
+                            <classname>Zend_Controller_Request_Abstract</classname>
+                            <varname>$request</varname>
+                            and a <classname>Zend_Controller_Response_Abstract</classname>
+                            <varname>$response</varname>.
+                        </para>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            <methodname>indexAction()</methodname> no longer needs to be
+                            defined, but is encouraged as the default action. This
+                            allows using the RewriteRouter and action controllers to
+                            specify different default action methods.
+                        </para>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            <methodname>__call()</methodname> should be overridden to handle any
+                            undefined actions automatically.
+                        </para>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            <methodname>_redirect()</methodname> now takes an optional second
+                            argument, the <acronym>HTTP</acronym> code to return with the redirect,
+                            and an optional third argument, <varname>$prependBase</varname>,
+                            that can indicate that the base <acronym>URL</acronym> registered with
+                            the request object should be prepended to the url specified.
+                        </para>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            The <varname>$_action</varname> property is no longer set. This property
+                            was a <classname>Zend_Controller_Dispatcher_Token</classname>,
                             which no longer exists in the current incarnation.
                             The sole purpose of the token was to provide
                             information about the requested controller, action,
-                            and URL parameters. This information is now
+                            and <acronym>URL</acronym> parameters. This information is now
                             available in the request object, and can be accessed
                             as follows:
                         </para>
@@ -737,19 +760,23 @@ public function __call($method, $args)
                 </itemizedlist>
             </listitem>
 
-            <listitem><para>
-                <classname>Zend_Controller_RewriteRouter::setRewriteBase()</classname> has
-                been removed. Use <classname>Zend_Controller_Front::setBaseUrl()</classname>
-                instead (or <classname>Zend_Controller_Request_Http::setBaseUrl()</classname>, if
-                using that request class).
-            </para></listitem>
-
-            <listitem><para>
-                <classname>Zend_Controller_Plugin_Interface</classname> was replaced
-                by <classname>Zend_Controller_Plugin_Abstract</classname>. All methods now
-                accept and return a <xref linkend="zend.controller.request" />
-                object instead of a dispatcher token.
-            </para></listitem>
+            <listitem>
+                <para>
+                    <methodname>Zend_Controller_RewriteRouter::setRewriteBase()</methodname> has
+                    been removed. Use <methodname>Zend_Controller_Front::setBaseUrl()</methodname>
+                    instead (or <methodname>Zend_Controller_Request_Http::setBaseUrl()</methodname>,
+                    if using that request class).
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <classname>Zend_Controller_Plugin_Interface</classname> was replaced
+                    by <classname>Zend_Controller_Plugin_Abstract</classname>. All methods now
+                    accept and return a <link linkend="zend.controller.request">The Request
+                    Object</link> instead of a dispatcher token.
+                </para>
+            </listitem>
         </itemizedlist>
     </sect2>
 </sect1>