[MANUAL] English:

- added a migration appendix
- moved all migration pages into this appendix

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

documentation/manual/en/manual.xml.in

@@ -125,14 +125,12 @@
         <xi:include href="module_specs/Zend_Controller-Plugins.xml" parse="xml" />
         <xi:include href="module_specs/Zend_Controller-Modular.xml" />
         <xi:include href="module_specs/Zend_Controller-Exceptions.xml" />
-        <xi:include href="module_specs/Zend_Controller-Migration.xml" />
     </chapter>
 
     <chapter id="zend.currency">
         <title>Zend_Currency</title>
         <xi:include href="module_specs/Zend_Currency-Introduction.xml" />
         <xi:include href="module_specs/Zend_Currency-Usage.xml" />
-        <xi:include href="module_specs/Zend_Currency-Migrating.xml" />
     </chapter>
 
     <chapter id="zend.date">
@@ -202,7 +200,6 @@
         <xi:include href="module_specs/Zend_File_Transfer-Introduction.xml" />
         <xi:include href="module_specs/Zend_File_Transfer-Validators.xml" />
         <xi:include href="module_specs/Zend_File_Transfer-Filters.xml" />
-        <xi:include href="module_specs/Zend_File_Transfer-Migration.xml" />
     </chapter>
 
     <chapter id="zend.filter">
@@ -213,7 +210,6 @@
         <xi:include href="module_specs/Zend_Filter-WritingFilters.xml" />
         <xi:include href="module_specs/Zend_Filter_Input.xml" />
         <xi:include href="module_specs/Zend_Filter-Inflector.xml" />
-        <xi:include href="module_specs/Zend_Filter-Migration.xml" />
     </chapter>
 
     <chapter id="zend.form">
@@ -251,7 +247,6 @@
         <xi:include href="module_specs/Zend_Http_Client.xml" />
         <xi:include href="module_specs/Zend_Http_Client-Advanced.xml" />
         <xi:include href="module_specs/Zend_Http_Client-Adapters.xml" />
-        <xi:include href="module_specs/Zend_Http_Client-Migration.xml" />
         <xi:include href="module_specs/Zend_Http_Cookie-Handling.xml" />
         <xi:include href="module_specs/Zend_Http_Response.xml" />
     </chapter>
@@ -304,7 +299,6 @@
         <xi:include href="module_specs/Zend_Locale-Parsing.xml" />
         <xi:include href="module_specs/Zend_Locale-DatesTimes.xml" />
         <xi:include href="module_specs/Zend_Locale-AppendixLanguages.xml" />
-        <xi:include href="module_specs/Zend_Locale-Migration.xml" />
     </chapter>
 
     <chapter id="zend.log">
@@ -361,7 +355,6 @@
         <xi:include href="module_specs/Zend_Navigation-Introduction.xml" />
         <xi:include href="module_specs/Zend_Navigation-Pages.xml" />
         <xi:include href="module_specs/Zend_Navigation-Containers.xml" />
-        <xi:include href="module_specs/Zend_Navigation-Migration.xml" />
     </chapter>
 
     <chapter id="zend.openid">
@@ -546,7 +539,6 @@
         <xi:include href="module_specs/Zend_Translate-SourceCreation.xml" />
         <xi:include href="module_specs/Zend_Translate-Additional.xml" />
         <xi:include href="module_specs/Zend_Translate-Plurals.xml" />
-        <xi:include href="module_specs/Zend_Translate-Migration.xml" />
     </chapter>
     <chapter id="zend.uri">
         <title>Zend_Uri</title>
@@ -559,7 +551,6 @@
         <xi:include href="module_specs/Zend_Validate-ValidatorChains.xml" />
         <xi:include href="module_specs/Zend_Validate-WritingValidators.xml" />
         <xi:include href="module_specs/Zend_Validate-Messages.xml" />
-        <xi:include href="module_specs/Zend_Validate-Migration.xml" />
     </chapter>
     <chapter id="zend.version">
         <title>Zend_Version</title>
@@ -572,7 +563,6 @@
         <xi:include href="module_specs/Zend_View-Scripts.xml" />
         <xi:include href="module_specs/Zend_View-Helpers.xml" parse="xml" />
         <xi:include href="module_specs/Zend_View-Abstract.xml" />
-        <xi:include href="module_specs/Zend_View-Migration.xml" />
     </chapter>
     <chapter id="zend.wildfire">
         <title>Zend_Wildfire</title>
@@ -585,6 +575,19 @@
         <xi:include href="module_specs/Zend_XmlRpc_Server.xml" />
     </chapter>
     <xi:include href="ref/requirements.xml" />
+    <appendix id="migration">
+        <title>Zend Framework Migration Notes</title>
+        <xi:include href="ref/migration-110.xml" />
+        <xi:include href="ref/migration-19.xml" />
+        <xi:include href="ref/migration-18.xml" />
+        <xi:include href="ref/migration-17.xml" />
+        <xi:include href="ref/migration-16.xml" />
+        <xi:include href="ref/migration-15.xml" />
+        <xi:include href="ref/migration-10.xml" />
+        <xi:include href="ref/migration-09.xml" />
+        <xi:include href="ref/migration-08.xml" />
+        <xi:include href="ref/migration-06.xml" />
+    </appendix>
     <xi:include href="ref/coding_standard.xml" />
     <xi:include href="ref/documentation-standard.xml" />
     <xi:include href="ref/project-structure.xml" />

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

@@ -1,785 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.controller.migration">
-    <title>Migrating from Previous Versions</title>
-
-    <para>
-        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>
-
-    <sect2 id="zend.controller.migration.fromoneseventooneeight">
-        <title>Migrating from 1.7.x to 1.8.0 or newer</title>
-
-        <sect3 id="zend.controller.migration.fromoneseventooneeight.router">
-            <title>Standard Route Changes</title>
-
-            <para>
-                As translated segments were introduced into the new standard
-                route, the '<emphasis>@</emphasis>' character is now a special character
-                in the beginning of a route segment. To be able to use it in a
-                static segment, you must escape it by prefixing it with second
-                '<emphasis>@</emphasis>' character. The same rule now applies for the
-                '<emphasis>:</emphasis>' character.
-            </para>
-        </sect3>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromonesixtooneseven">
-        <title>Migrating from 1.6.x to 1.7.0 or newer</title>
-
-        <sect3 id="zend.controller.migration.fromonesixtooneseven.dispatcher">
-            <title>Dispatcher Interface Changes</title>
-
-            <para>
-                Users brought to our attention the fact that
-                <classname>Zend_Controller_Action_Helper_ViewRenderer</classname> were
-                using a method of the dispatcher abstract class that was not in
-                the dispatcher interface. We have now added the following method to
-                ensure that custom dispatchers will continue to work with the
-                shipped implementations:
-            </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>
-            </itemizedlist>
-        </sect3>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromoneohtoonesix">
-        <title>Migrating from 1.5.x to 1.6.0 or Newer</title>
-
-        <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
-            <title>Dispatcher Interface Changes</title>
-
-            <para>
-                Users brought to our attention the fact that
-                <classname>Zend_Controller_Front</classname> and
-                <classname>Zend_Controller_Router_Route_Module</classname> were each
-                using methods of the dispatcher that were not in the dispatcher
-                interface. We have now added the following three methods to
-                ensure that custom dispatchers will continue to work with the
-                shipped implementations:
-            </para>
-
-            <itemizedlist>
-                <listitem><para>
-                    <methodname>getDefaultModule()</methodname>: should return the name of
-                    the default module.
-                </para></listitem>
-
-                <listitem><para>
-                    <methodname>getDefaultControllerName()</methodname>: should return the
-                    name of the default controller.
-                </para></listitem>
-
-                <listitem><para>
-                    <methodname>getDefaultAction()</methodname>: should return the
-                    name of the default action.
-                </para></listitem>
-            </itemizedlist>
-        </sect3>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromoneohtoonefive">
-        <title>Migrating from 1.0.x to 1.5.0 or Newer</title>
-
-        <para>
-            Though most basic functionality remains the same, and all documented
-            functionality remains the same, there is one particular
-            <emphasis>undocumented</emphasis> "feature" that has changed.
-        </para>
-
-        <para>
-            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 <acronym>PHP</acronym>
-            functions are not case sensitive, you <emphasis>could</emphasis>
-            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
-            <acronym>PHP</acronym>, both will execute the same method.
-        </para>
-
-        <para>
-            This causes issues with the ViewRenderer when resolving view
-            scripts. The canonical, documented way is that all word separators
-            are converted to dashes, and the words lowercased. This creates
-            a semantic tie between the actions and view scripts, and the
-            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 -- <filename>camelcased.phtml</filename> instead of
-            <filename>camel-cased.phtml</filename>.
-        </para>
-
-        <para>
-            Some developers relied on this "feature", which was never intended.
-            Several changes in the 1.5.0 tree, however, made it so that the
-            ViewRenderer no longer resolves these paths; the semantic tie is now
-            enforced. First among these, the dispatcher now enforces case
-            sensitivity in action names. What this means is that referring to
-            your actions on the url using camelCasing will no longer resolve to
-            the same method as using word separators (i.e., 'camel-casing').
-            This leads to the ViewRenderer now only honoring the word-separated
-            actions when resolving view scripts.
-        </para>
-
-        <para>
-            If you find that you were relying on this "feature", you have several
-            options:
-        </para>
-
-        <itemizedlist>
-            <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>
-
-            <listitem>
-                <para>
-                    Second best option: The ViewRenderer now delegates view
-                    script resolution to <classname>Zend_Filter_Inflector</classname>; you
-                    can modify the rules of the inflector to no longer separate
-                    the words of an action with a dash:
-                </para>
-
-                <programlisting language="php"><![CDATA[
-$viewRenderer =
-    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
-$inflector = $viewRenderer->getInflector();
-$inflector->setFilterRule(':action', array(
-    new Zend_Filter_PregReplace(
-        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
-        ''
-    ),
-    'StringToLower'
-));
-]]></programlisting>
-
-                <para>
-                    The above code will modify the inflector to no longer
-                    separate the words with dash; you may also want to remove
-                    the 'StringToLower' filter if you <emphasis>do</emphasis>
-                    want the actual view script names camelCased as well.
-                </para>
-
-                <para>
-                    If renaming your view scripts would be too tedious or time
-                    consuming, this is your best option until you can find the
-                    time to do so.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    Least desirable option: You can force the dispatcher to
-                    dispatch camelCased action names with a new front controller
-                    flag, <property>useCaseSensitiveActions</property>:
-                </para>
-
-                <programlisting language="php"><![CDATA[
-$front->setParam('useCaseSensitiveActions', true);
-]]></programlisting>
-
-                <para>
-                    This will allow you to use camelCasing on the url and still
-                    have it resolve to the same action as when you use word
-                    separators. However, this will mean that the original issues
-                    will cascade on through; you will likely need to use the
-                    second option above in addition to this for things to work
-                    at all reliably.
-                </para>
-
-                <para>
-                    Note, also, that usage of this flag will raise a notice that
-                    this usage is deprecated.
-                </para>
-            </listitem>
-        </itemizedlist>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromzeroninethree">
-        <title>Migrating from 0.9.3 to 1.0.0RC1 or Newer</title>
-
-        <para>
-            The principal changes introduced in 1.0.0RC1 are the introduction of
-            and default enabling of the
-            <link
-                linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
-            plugin and the <link
-                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>
-            action helper. Please read the documentation to each thoroughly to
-            see how they work and what effect they may have on your
-            applications.
-        </para>
-
-        <para>
-            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 <property>noErrorHandler</property>:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-$front->setParam('noErrorHandler', true);
-]]></programlisting>
-
-        <para>
-            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 <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
-            <classname>ViewRenderer</classname> in your front controller bootstrap prior
-            to dispatching:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-// Assuming $front is an instance of Zend_Controller_Front
-$front->setParam('noViewRenderer', true);
-]]></programlisting>
-
-        <para>
-            However, this is not a good long term strategy, as it means most
-            likely you'll be writing more code.
-        </para>
-
-        <para>
-            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
-            the following is happening, you'll need to make changes:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>Calls to <command>$this->render();</command></para>
-            </listitem>
-            <listitem>
-                <para>Calls to <command>$this->_forward();</command></para>
-            </listitem>
-            <listitem>
-                <para>Calls to <command>$this->_redirect();</command></para>
-            </listitem>
-            <listitem>
-                <para>Calls to the <classname>Redirector</classname> action helper</para>
-            </listitem>
-        </itemizedlist>
-
-        <para>
-            The easiest change is to disable auto-rendering for that method:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-$this->_helper->viewRenderer->setNoRender();
-]]></programlisting>
-
-        <para>
-            If you find that none of your action methods are rendering,
-            forwarding, or redirecting, you will likely want to put the above
-            line in your <methodname>preDispatch()</methodname> or <methodname>init()</methodname>
-            methods:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-public function preDispatch()
-{
-    // disable view script autorendering
-    $this->_helper->viewRenderer->setNoRender()
-    // .. do other things...
-}
-]]></programlisting>
-
-        <para>
-            If you are calling <methodname>render()</methodname>, and you're using <link
-                linkend="zend.controller.modular">the Conventional Modular
-                directory structure</link>, you'll want to change your code to
-            make use of autorendering:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    If you're rendering multiple view scripts in a single
-                    action, you don't need to change a thing.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    If you're simply calling <methodname>render()</methodname> with no
-                    arguments, you can remove such lines.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    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
-                    <command>$this->_helper->viewRenderer();</command>.
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        <para>
-            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
-            <classname>ViewRenderer</classname>. Please read the <link
-                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer
-                documentation</link> for information on these methods.
-        </para>
-
-        <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 <classname>ViewRenderer</classname> with this object. This can
-            be done easily at any time.
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    Prior to dispatching a front controller instance:
-                </para>
-
-                <programlisting language="php"><![CDATA[
-// Assuming $view has already been defined
-$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
-Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
-]]></programlisting>
-            </listitem>
-
-            <listitem>
-                <para>
-                    Any time during the bootstrap process:
-                </para>
-
-                <programlisting language="php"><![CDATA[
-$viewRenderer =
-    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
-$viewRenderer->setView($view);
-]]></programlisting>
-            </listitem>
-        </itemizedlist>
-
-        <para>
-            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 <classname>ViewRenderer</classname>.
-        </para>
-
-        <para>
-            We encourage you to adapt your code to use the
-            <classname>ErrorHandler</classname> and <classname>ViewRenderer</classname> as they are
-            now core functionality.
-        </para>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromzeroninetwo">
-        <title>Migrating from 0.9.2 to 0.9.3 or Newer</title>
-
-        <para>
-            0.9.3 introduces <link
-                linkend="zend.controller.actionhelpers">action helpers</link>.
-            As part of this change, the following methods have been removed as
-            they are now encapsulated in the <link
-                linkend="zend.controller.actionhelpers.redirector">redirector
-                action helper</link>:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    <methodname>setRedirectCode()</methodname>; use
-                    <methodname>Zend_Controller_Action_Helper_Redirector::setCode()</methodname>.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <methodname>setRedirectPrependBase()</methodname>; use
-                    <methodname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</methodname>.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <methodname>setRedirectExit()</methodname>; use
-                    <methodname>Zend_Controller_Action_Helper_Redirector::setExit()</methodname>.
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        <para>
-            Read the <link linkend="zend.controller.actionhelpers">action
-                helpers documentation</link> for more information on how to
-            retrieve and manipulate helper objects, and the <link
-                linkend="zend.controller.actionhelpers.redirector">redirector
-                helper documentation</link> for more information on setting
-            redirect options (as well as alternate methods for redirecting).
-        </para>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromzerosix">
-        <title>Migrating from 0.6.0 to 0.8.0 or Newer</title>
-
-        <para>
-            Per previous changes, the most basic usage of the <acronym>MVC</acronym> components
-            remains the same:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-Zend_Controller_Front::run('/path/to/controllers');
-]]></programlisting>
-
-        <para>
-            However, the directory structure underwent an overhaul, several
-            components were removed, and several others either renamed or added.
-            Changes include:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    <classname>Zend_Controller_Router</classname> was removed in favor of
-                    the rewrite router.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    <classname>Zend_Controller_RewriteRouter</classname> was renamed to
-                    <classname>Zend_Controller_Router_Rewrite</classname>, and promoted to
-                    the standard router shipped with the framework;
-                    <classname>Zend_Controller_Front</classname> will use it by default if
-                    no other router is supplied.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    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 <acronym>MVC</acronym>, and has support for <link
-                        linkend="zend.controller.modular">controller
-                        modules</link>.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    <classname>Zend_Controller_Router_StaticRoute</classname> was renamed
-                    to <classname>Zend_Controller_Router_Route_Static</classname>.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    <classname>Zend_Controller_Dispatcher</classname> was renamed
-                    <classname>Zend_Controller_Dispatcher_Standard</classname>.
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    <methodname>Zend_Controller_Action::_forward()</methodname>'s arguments
-                    have changed. The signature is now:
-                </para>
-
-                <programlisting language="php"><![CDATA[
-final protected function _forward($action,
-                                  $controller = null,
-                                  $module = null,
-                                  array $params = null);
-]]></programlisting>
-
-                <para>
-                    <varname>$action</varname> is always required; if no controller is
-                    specified, an action in the current controller is assumed.
-                    <varname>$module</varname> is always ignored unless
-                    <varname>$controller</varname> is specified. Finally, any
-                    <varname>$params</varname> provided will be appended to the
-                    request object. If you do not require the controller or
-                    module, but still need to pass parameters, simply specify
-                    <constant>NULL</constant> for those values.
-                </para>
-            </listitem>
-        </itemizedlist>
-    </sect2>
-
-    <sect2 id="zend.controller.migration.fromzerotwo">
-        <title>Migrating from 0.2.0 or before to 0.6.0</title>
-
-        <para>
-            The most basic usage of the <acronym>MVC</acronym> components has not changed; you can
-            still do each of the following:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-Zend_Controller_Front::run('/path/to/controllers');
-]]></programlisting>
-
-        <programlisting language="php"><![CDATA[
-/* -- create a router -- */
-$router = new Zend_Controller_RewriteRouter();
-$router->addRoute('user',
-                  'user/:username',
-                  array('controller' => 'user', 'action' => 'info')
-);
-
-/* -- set it in a controller -- */
-$ctrl = Zend_Controller_Front::getInstance();
-$ctrl->setRouter($router);
-
-/* -- set controller directory and dispatch -- */
-$ctrl->setControllerDirectory('/path/to/controllers');
-$ctrl->dispatch();
-]]></programlisting>
-
-        <para>
-            We encourage use of the Response object to aggregate content and
-            headers. This will allow for more flexible output format switching
-            (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>,
-            and then render the response using your own logic. A future version
-            of the front controller may enforce use of the response object via
-            output buffering.
-        </para>
-
-        <para>
-            There are many additional features that extend the existing <acronym>API</acronym>,
-            and these are noted in the documentation.
-        </para>
-
-        <para>
-            The main changes you will need to be aware of will be found when
-            subclassing the various components. Key amongst these are:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    <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:
-                </para>
-
-                <itemizedlist>
-                    <listitem>
-                        <para>
-                            Set <methodname>throwExceptions()</methodname> in the front
-                            controller:
-                        </para>
-                        <programlisting language="php"><![CDATA[
-$front->throwExceptions(true);
-]]></programlisting>
-                    </listitem>
-
-                    <listitem>
-                        <para>
-                            Set <methodname>renderExceptions()</methodname> in the response
-                            object:
-                        </para>
-                        <programlisting language="php"><![CDATA[
-$response->renderExceptions(true);
-$front->setResponse($response);
-$front->dispatch();
-
-// or:
-$front->returnResponse(true);
-$response = $front->dispatch();
-$response->renderExceptions(true);
-echo $response;
-]]></programlisting>
-                    </listitem>
-                </itemizedlist>
-            </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>
-                    <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</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>
-                            <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 <acronym>URL</acronym> parameters. This information is now
-                            available in the request object, and can be accessed
-                            as follows:
-                        </para>
-
-                        <programlisting language="php"><![CDATA[
-// Retrieve the requested controller name
-// Access used to be via: $this->_action->getControllerName().
-// The example below uses getRequest(), though you may also directly
-// access the $_request property; using getRequest() is recommended as
-// a parent class may override access to the request object.
-$controller = $this->getRequest()->getControllerName();
-
-// Retrieve the requested action name
-// Access used to be via: $this->_action->getActionName().
-$action = $this->getRequest()->getActionName();
-
-// Retrieve the request parameters
-// This hasn't changed; the _getParams() and _getParam() methods simply
-// proxy to the request object now.
-$params = $this->_getParams();
-// request 'foo' parameter, using 'default' as default value if not found
-$foo = $this->_getParam('foo', 'default');
-]]></programlisting>
-                    </listitem>
-
-                    <listitem>
-                        <para>
-                            <methodname>noRouteAction()</methodname> has been removed. The
-                            appropriate way to handle non-existent action
-                            methods should you wish to route them to a default
-                            action is using <methodname>__call()</methodname>:
-                        </para>
-
-                        <programlisting language="php"><![CDATA[
-public function __call($method, $args)
-{
-    // If an unmatched 'Action' method was requested, pass on to the
-    // default action method:
-    if ('Action' == substr($method, -6)) {
-        return $this->defaultAction();
-    }
-
-    throw new Zend_Controller_Exception('Invalid method called');
-}
-]]></programlisting>
-                    </listitem>
-                </itemizedlist>
-            </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>
-<!--
-vim:se ts=4 sw=4 et:
--->

documentation/manual/en/module_specs/Zend_Currency-Migrating.xml

@@ -1,113 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.currency.migration">
-
-    <title>Migrating from Previous Versions</title>
-
-    <para>
-        The <acronym>API</acronym> of <classname>Zend_Currency</classname> has changed in the past
-        to enhance usability. If you started using <classname>Zend_Currency</classname> with a
-        version which is mentioned in this chapter follow the guidelines below
-        to migrate your scripts to the new <acronym>API</acronym>.
-    </para>
-
-    <sect2 id="zend.currency.usage.migration.fromonezerotwo">
-
-        <title>Migrating from 1.0.2 to 1.0.3 or Newer</title>
-
-        <para>
-            Creating an object of <classname>Zend_Currency</classname> has become simpler.
-            You no longer have to give a script or set it to <constant>NULL</constant>. The optional
-            script parameter is now an option which can be set through the
-            <methodname>setFormat()</methodname> method.
-        </para>
-
-        <programlisting language="php"><![CDATA[
-$currency = new Zend_Currency($currency, $locale);
-]]></programlisting>
-
-        <para>
-            The <methodname>setFormat()</methodname> method takes now an array of options. These
-            options are set permanently and override all previously set values. Also a new option
-            'precision' has been added. The following options have been refactored:
-        </para>
-
-        <itemizedlist mark='opencircle'>
-            <listitem>
-                <para>
-                    <emphasis>position</emphasis>:
-                    Replacement for the old 'rules' parameter.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>script</emphasis>:
-                    Replacement for the old 'script' parameter.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>format</emphasis>:
-                    Replacement for the old 'locale' parameter which does not
-                    set new currencies but only the number format.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>display</emphasis>:
-                    Replacement for the old 'rules' parameter.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>precision</emphasis>:
-                    New parameter.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>name</emphasis>:
-                    Replacement for the ole 'rules' parameter. Sets the full
-                    currencies name.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>currency</emphasis>:
-                    New parameter.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>symbol</emphasis>:
-                    New parameter.
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        <programlisting language="php"><![CDATA[
-$currency->setFormat(array $options);
-]]></programlisting>
-
-        <para>
-            The <methodname>toCurrency()</methodname> method no longer supports the optional
-            'script' and 'locale' parameters. Instead it takes an options array which
-            can contain the same keys as for the <methodname>setFormat()</methodname> method.
-        </para>
-
-        <programlisting language="php"><![CDATA[
-$currency->toCurrency($value, array $options);
-]]></programlisting>
-
-        <para>
-            The methods <methodname>getSymbol()</methodname>,
-            <methodname>getShortName()</methodname>, <methodname>getName()</methodname>,
-            <methodname>getRegionList()</methodname> and
-            <methodname>getCurrencyList()</methodname> are no longer static and can be called
-            from within the object. They return the set values of the object if no
-            parameter has been set.
-        </para>
-
-    </sect2>
-
-</sect1>

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

@@ -1,26 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.filter.migration">
-    <title>Migrating from Previous Versions</title>
-
-    <para>
-        This chapter documents primarily backwards compatibility breaks made in
-        <classname>Zend_Filter</classname>, and should serve to aid in migration from previous
-        versions.
-    </para>
-
-    <sect2 id="zend.filter.migration.zf2105">
-        <title>Migrating from versions prior to 1.9</title>
-
-        <para>
-            Prior to the 1.9 release, <classname>Zend_Filter</classname> allowed
-            the usage of the static <methodname>get()</methodname> method. As with
-            release 1.9 this method has been renamed to
-            <methodname>filterStatic()</methodname> to be more descriptive. The
-            old <methodname>get()</methodname> method is marked as deprecated.
-        </para>
-    </sect2>
-</sect1>
-<!--
-vim:se ts=4 sw=4 et:
--->

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

@@ -1,108 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.http.client.migration">
-
-    <title>Migrating from previous versions</title>
-
-    <para>
-        While the external <acronym>API</acronym> of <classname>Zend_Http_Client</classname> has remained
-        consistent throughout the 1.x branch of Zend Framework, some changes were introduced
-        to the internal structure of <classname>Zend_Http_Client</classname> and its related
-        classes.
-    </para>
-
-    <para>
-        These changes should have no affect on code using <classname>Zend_Http_Client</classname>
-        - but may have an effect on <acronym>PHP</acronym> classes overloading or extending it. If your application
-        subclasses <classname>Zend_Http_Client</classname>, it is highly recommended to review
-        the following changes before upgrading Zend Framework.
-    </para>
-
-    <sect2 id="zend.http.client.migration.tozf19">
-        <title>Migrating from 1.8 or older to 1.9 or newer</title>
-        <sect3 id="zend.http.client.migration.tozf19.fileuploadsarray">
-            <title>Changes to internal uploaded file information storage</title>
-
-            <para>
-                In version 1.9 of Zend Framework, there has been a change in the way
-                <classname>Zend_Http_Client</classname> internally stores information about
-                files to be uploaded, set using the <methodname>Zend_Http_Client::setFileUpload()</methodname>
-                method.
-            </para>
-
-            <para>
-                This change was introduced in order to allow multiple files to be uploaded
-                with the same form name, as an array of files. More information about this issue
-                can be found in <ulink url="http://framework.zend.com/issues/browse/ZF-5744">this bug report</ulink>.
-            </para>
-
-            <example id="zend.http.client.migration.tozf19.fileuploadsarray.example">
-                <title>Internal storage of uploaded file information</title>
-
-                <programlisting language="php"><![CDATA[
-// Upload two files with the same form element name, as an array
-$client = new Zend_Http_Client();
-$client->setFileUpload('file1.txt',
-                       'userfile[]',
-                       'some raw data',
-                       'text/plain');
-$client->setFileUpload('file2.txt',
-                       'userfile[]',
-                       'some other data',
-                       'application/octet-stream');
-
-// In Zend Framework 1.8 or older, the value of
-// the protected member $client->files is:
-// $client->files = array(
-//     'userfile[]' => array('file2.txt',
-                             'application/octet-stream',
-                             'some other data')
-// );
-
-// In Zend Framework 1.9 or newer, the value of $client->files is:
-// $client->files = array(
-//     array(
-//         'formname' => 'userfile[]',
-//         'filename' => 'file1.txt,
-//         'ctype'    => 'text/plain',
-//         'data'     => 'some raw data'
-//     ),
-//     array(
-//         'formname' => 'userfile[]',
-//         'filename' => 'file2.txt',
-//         'formname' => 'application/octet-stream',
-//         'formname' => 'some other data'
-//     )
-// );
-]]></programlisting>
-            </example>
-
-            <para>
-                As you can see, this change permits the usage of the same form element name with
-                more than one file - however, it introduces a subtle backwards-compatibility change
-                and as such should be noted.
-            </para>
-        </sect3>
-
-        <sect3 id="zend.http.client.migration.tozf19.getparamsrecursize">
-            <title>Deprecation of Zend_Http_Client::_getParametersRecursive()</title>
-
-            <para>
-                Starting from version 1.9, the protected method <methodname>_getParametersRecursive()</methodname>
-                is no longer used by <classname>Zend_Http_Client</classname> and is deprecated.
-                Using it will cause an E_NOTICE message to be emitted by <acronym>PHP</acronym>.
-            </para>
-
-            <para>
-                If you subclass <classname>Zend_Http_Client</classname> and call this method, you
-                should look into using the <methodname>Zend_Http_Client::_flattenParametersArray()</methodname>
-                static method instead.
-            </para>
-
-            <para>
-                Again, since this <classname>_getParametersRecursive</classname> is a protected method,
-                this change will only affect users who subclass <classname>Zend_Http_Client</classname>.
-            </para>
-        </sect3>
-    </sect2>
-</sect1>

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

@@ -1,218 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.locale.migration">
-
-    <title>Migrating from previous versions</title>
-
-    <para>
-        The <acronym>API</acronym> of <classname>Zend_Locale</classname> has changed from time to time.
-        If you started to use <classname>Zend_Locale</classname> and its subcomponents
-        in earlier versions follow the guidelines below to migrate your scripts to
-        use the new <acronym>API</acronym>.
-    </para>
-
-    <sect2 id="zend.locale.migration.fromoneeighttoonenine">
-        <title>Migrating from 1.8 to 1.9 or newer</title>
-        <sect3 id="zend.locale.migration.fromoneeighttoonenine.depreciated">
-            <title>Depreciated methods</title>
-
-            <para>
-                Some specialized translation methods have been depreciated because they duplicate
-                existing behaviour. Note that the old methods will still work, but a user notice is
-                triggered which describes the new call. The methods will be erased with 2.0.
-                See the following list for old and new method call.
-            </para>
-
-            <table id="zend.locale.migration.fromoneeighttoonenine.depreciated.table-1">
-
-                <title>List of measurement types</title>
-
-                <tgroup cols="2">
-                    <thead>
-                        <row>
-                            <entry>Old call</entry>
-                            <entry>New call</entry>
-                        </row>
-                    </thead>
-                    <tbody>
-                        <row>
-                            <entry>getLanguageTranslationList($locale)</entry>
-                            <entry>getTranslationList('language', $locale)</entry>
-                        </row>
-                        <row>
-                            <entry>getScriptTranslationList($locale)</entry>
-                            <entry>getTranslationList('script', $locale)</entry>
-                        </row>
-                        <row>
-                            <entry>getCountryTranslationList($locale)</entry>
-                            <entry>getTranslationList('territory', $locale, 2)</entry>
-                        </row>
-                        <row>
-                            <entry>getTerritoryTranslationList($locale)</entry>
-                            <entry>getTranslationList('territory', $locale, 1)</entry>
-                        </row>
-                        <row>
-                            <entry>getLanguageTranslation($value, $locale)</entry>
-                            <entry>getTranslation($value, 'language', $locale)</entry>
-                        </row>
-                        <row>
-                            <entry>getScriptTranslation($value, $locale)</entry>
-                            <entry>getTranslation($value, 'script', $locale)</entry>
-                        </row>
-                        <row>
-                            <entry>getCountryTranslation($value, $locale)</entry>
-                            <entry>getTranslation($value, 'country', $locale)</entry>
-                        </row>
-                        <row>
-                            <entry>getTerritoryTranslation($value, $locale)</entry>
-                            <entry>getTranslation($value, 'territory', $locale)</entry>
-                        </row>
-                    </tbody>
-                </tgroup>
-            </table>
-        </sect3>
-    </sect2>
-
-    <sect2 id="zend.locale.migration.fromoneseventooneeight">
-        <title>Migrating from 1.7 to 1.8 or newer</title>
-        <sect3 id="zend.locale.migration.fromoneseventooneeight.defaultcaching">
-            <title>Default caching</title>
-
-            <para>
-                As with Zend Framework 1.8 a default caching was added. The reason behind this
-                change was, that most users had performance problems but did not add caching at
-                all. As the I18n core is a bottleneck when no caching is used we decided to add
-                a default caching when no cache has been set to <classname>Zend_Locale</classname>.
-            </para>
-
-            <para>
-                Sometimes it is still wanted to prevent caching at all even if this decreases
-                performance. To do so you can simply disable caching by using the
-                <methodname>disableCache()</methodname> method.
-            </para>
-
-            <example id="zend.locale.migration.fromoneseventooneeight.example">
-                <title>Disabling default caching</title>
-
-                <programlisting language="php"><![CDATA[
-Zend_Locale::disableCache(true);
-]]></programlisting>
-            </example>
-        </sect3>
-    </sect2>
-
-    <sect2 id="zend.locale.migration.fromonesixtooneseven">
-        <title>Migrating from 1.6 to 1.7 or newer</title>
-        <sect3 id="zend.locale.migration.fromonesixtooneseven.islocale">
-            <title>Changes when using isLocale()</title>
-
-            <para>
-                According to the coding standards isLocale() had to be changed to return
-                a boolean. In previous releases a string was returned on success. For
-                release 1.7 a compatibility mode has been added which allows to use the
-                old behaviour of a returned string, but it triggers a user warning to
-                mention you to change to the new behaviour. The rerouting which the old
-                behaviour of isLocale() could have done is no longer neccessary as all
-                I18N will now process a rerouting themself.
-            </para>
-
-            <para>
-                To migrate your scripts to the new <acronym>API</acronym>, simply use the method as shown below.
-            </para>
-
-            <example id="zend.locale.migration.fromonesixtooneseven.example">
-                <title>How to change isLocale() from 1.6 to 1.7</title>
-
-                <programlisting language="php"><![CDATA[
-// Example for 1.6
-if ($locale = Zend_Locale::isLocale($locale)) {
-    // do something
-}
-
-// Same example for 1.7
-
-// You should change the compatiblity mode to prevent user warnings
-// But you can do this in your bootstrap
-Zend_Locale::$compatibilityMode = false;
-
-if (Zend_Locale::isLocale($locale)) {
-}
-]]></programlisting>
-
-                <para>
-                    Note that you can use the second parameter to see if the locale is correct without
-                    processing a rerouting.
-                </para>
-
-                <programlisting language="php"><![CDATA[
-// Example for 1.6
-if ($locale = Zend_Locale::isLocale($locale, false)) {
-    // do something
-}
-
-// Same example for 1.7
-
-// You should change the compatiblity mode to prevent user warnings
-// But you can do this in your bootstrap
-Zend_Locale::$compatibilityMode = false;
-
-if (Zend_Locale::isLocale($locale, false)) {
-    if (Zend_Locale::isLocale($locale, true)) {
-        // no locale at all
-    }
-
-    // original string is no locale but can be rerouted
-}
-]]></programlisting>
-
-            </example>
-
-        </sect3>
-
-        <sect3 id="zend.locale.migration.fromonesixtooneseven.getdefault">
-            <title>Changes when using getDefault()</title>
-
-            <para>
-                The meaning of the getDefault() method has been change due to the fact that we
-                integrated a framework locale which can be set with setDefault(). It does no
-                longer return the locale chain but only the set framework locale.
-            </para>
-
-            <para>
-                To migrate your scripts to the new <acronym>API</acronym>, simply use the method as shown below.
-            </para>
-
-            <example id="zend.locale.migration.fromonesixtooneseven.getdefault.example">
-                <title>How to change getDefault() from 1.6 to 1.7</title>
-
-                <programlisting language="php"><![CDATA[
-// Example for 1.6
-$locales = $locale->getDefault(Zend_Locale::BROWSER);
-
-// Same example for 1.7
-
-// You should change the compatiblity mode to prevent user warnings
-// But you can do this in your bootstrap
-Zend_Locale::$compatibilityMode = false;
-
-$locale = Zend_Locale::getOrder(Zend_Locale::BROWSER);
-]]></programlisting>
-
-                <para>
-                    Note that the second parameter of the old getDefault() implementation is not
-                    available anymore, but the returned values are the same.
-                </para>
-            </example>
-
-            <note>
-                <para>
-                    Per default the old behaviour is still active, but throws a user warning.
-                    When you have changed your code to the new behaviour you should also change
-                    the compatibility mode to false so that no warning is thrown anymore.
-                </para>
-            </note>
-
-        </sect3>
-
-    </sect2>
-</sect1>

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

@@ -1,101 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.navigation.migration">
-    <title>Migrating from Previous Versions</title>
-
-    <para>
-        This chapter documents primarily backwards compatibility breaks made in
-        <classname>Zend_Navigation</classname> and <classname>Zend_View_Helper_Navigation</classname>, and should serve to aid
-        in migration from previous versions.
-    </para>
-
-    <sect2 id="zend.view.navigation.zf7341">
-        <title>Migrating from versions prior to 1.9</title>
-
-        <para>
-            Prior to the 1.9 release, the menu helper
-            (<classname>Zend_View_Helper_Navigation_Menu</classname>) did not
-            render sub menus correctly. When the <code>onlyActiveBranch</code>
-            was <constant>TRUE</constant> and the option <code>renderParents</code>
-            <constant>FALSE</constant>, nothing would be rendered if the deepest active
-            page was at a depth lower than the <code>minDepth</code> option.
-        </para>
-
-        <para>
-            In simpler words; if <code>minDepth</code> was set to <code>1</code>
-            and the active page was at one of the first level pages, nothing
-            would be rendered, as the following example shows.
-        </para>
-
-        <para>
-            Consider the following container setup:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-<?php
-$container = new Zend_Navigation(array(
-    array(
-        'label' => 'Home',
-        'uri'   => '#'
-    ),
-    array(
-        'label'  => 'Products',
-        'uri'    => '#',
-        'active' => true,
-        'pages'  => array(
-            array(
-                'label' => 'Server',
-                'uri'   => '#'
-            ),
-            array(
-                'label' => 'Studio',
-                'uri'   => '#'
-            )
-        )
-    ),
-    array(
-        'label' => 'Solutions',
-        'uri'   => '#'
-    )
-));
-]]></programlisting>
-
-        <para>
-            The following code is used in a view script:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-<?php echo $this->navigation()->menu()->renderMenu($container, array(
-    'minDepth'         => 1,
-    'onlyActiveBranch' => true,
-    'renderParents'    => false
-)); ?>
-]]></programlisting>
-
-        <para>
-            Before release 1.9, the code snippet above would output nothing.
-        </para>
-
-        <para>
-            Since release 1.9, the <methodname>_renderDeepestMenu()</methodname> method in
-            <classname>Zend_View_Helper_Navigation_Menu</classname> will accept
-            active pages at one level below <code>minDepth</code>, as long as
-            the page has children.
-        </para>
-
-        <para>
-            The same code snippet will now output the following:
-        </para>
-
-        <programlisting language="html"><![CDATA[
-<ul class="navigation">
-    <li>
-        <a href="#">Server</a>
-    </li>
-    <li>
-        <a href="#">Studio</a>
-    </li>
-</ul>
-]]></programlisting>
-    </sect2>
-</sect1>

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

@@ -1,76 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.translate.migration">
-
-    <title>Migrating from previous versions</title>
-
-    <para>
-        The <acronym>API</acronym> of <classname>Zend_Translate</classname> has changed from time to time.
-        If you started to use <classname>Zend_Translate</classname> and its subcomponents
-        in earlier versions follow the guidelines below to migrate your scripts to
-        use the new <acronym>API</acronym>.
-    </para>
-
-    <sect2 id="zend.translate.migration.fromonesixtooneseven">
-        <title>Migrating from 1.6 to 1.7 or newer</title>
-        <sect3 id="zend.translate.migration.fromonesixtooneseven.languages">
-            <title>Setting languages</title>
-
-            <para>
-                When using automatic detection of languages, or setting languages manually
-                to <classname>Zend_Translate</classname> you may have mentioned that from time to time a
-                notice is thrown about not added or empty translations. In some previous
-                release also an exception was raised in some cases.
-            </para>
-
-            <para>
-                The reason is, that when a user requests a non existing language, you
-                have no simple way to detect what's going wrong. So we added those
-                notices which show up in your log and tell you that the user requested
-                a language which you do not support. Note that the code, even when
-                we trigger such an notice, keeps working without problems.
-            </para>
-
-            <para>
-                But when you use a own error or exception handler, like xdebug, you
-                will get all notices returned, even if this was not your intention.
-                This is due to the fact that these handlers override all settings
-                from within <acronym>PHP</acronym>.
-            </para>
-
-            <para>
-                To get rid of these notices you can simply set the new option
-                'disableNotices' to true. It defaults to false.
-            </para>
-
-            <example id="zend.translate.migration.fromonesixtooneseven.example">
-                <title>Setting languages without getting notices</title>
-
-                <para>
-                    Let's assume that we have 'en' available and our user requests
-                    'fr' which is not in our portfolio of translated languages.
-                </para>
-
-                <programlisting language="php"><![CDATA[
-$language = new Zend_Translate('gettext',
-                               '/path/to/translations',
-                               'auto');
-]]></programlisting>
-
-                <para>
-                    In this case we will get an notice about a not available language 'fr'.
-                    Simply add the option and the notices will be disabled.
-                </para>
-
-                <programlisting language="php"><![CDATA[
-$language = new Zend_Translate('gettext',
-                               '/path/to/translations',
-                               'auto',
-                               array('disableNotices' => true));
-]]></programlisting>
-
-            </example>
-
-        </sect3>
-    </sect2>
-</sect1>

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

@@ -1,59 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Reviewed: no -->
-<sect1 id="zend.view.migration">
-    <title>Migrating from Previous Versions</title>
-
-    <para>
-        This chapter documents primarily backwards compatibility breaks made in
-        <classname>Zend_View</classname>, and should serve to aid in migration from previous versions.
-    </para>
-
-    <sect2 id="zend.view.migration.zf5748">
-        <title>Migrating from versions prior to 1.7.5</title>
-
-        <para>
-            Prior to the 1.7.5 release, the Zend Framework team was notified of
-            a potential Local File Inclusion (LFI) vulnerability in the
-            <methodname>Zend_View::render()</methodname> method. Prior to 1.7.5, the method
-            allowed, by default, the ability to specify view scripts that
-            included parent directory notation (e.g., "../" or "..\"). This
-            opens the possibility for an LFI attack if unfiltered user input is
-            passed to the <methodname>render()</methodname> method:
-        </para>
-
-        <programlisting language="php"><![CDATA[
-// Where $_GET['foobar'] = '../../../../etc/passwd'
-echo $view->render($_GET['foobar']); // LFI inclusion
-]]></programlisting>
-
-        <para>
-            <classname>Zend_View</classname> now by default raises an exception when such
-            a view script is requested.
-        </para>
-
-        <sect3 id="zend.view.migration.zf5748.disabling">
-            <title>Disabling LFI protection for the render() method</title>
-
-            <para>
-                Since a number of developers reported that they were using such
-                notation within their applications that was <emphasis>not</emphasis>
-                the result of user input, a special flag was created to allow
-                disabling the default protection. You have two methods for doing so:
-                by passing the 'lfiProtectionOn' key to the constructor options, or
-                by explicitly calling the <methodname>setLfiProtection()</methodname> method.
-            </para>
-
-            <programlisting language="php"><![CDATA[
-// Disabling via constructor
-$view = new Zend_View(array('lfiProtectionOn' => false));
-
-// Disabling via exlicit method call:
-$view = new Zend_View();
-$view->setLfiProtection(false);
-]]></programlisting>
-        </sect3>
-    </sect2>
-</sect1>
-<!--
-vim:se ts=4 sw=4 et:
--->

documentation/manual/en/ref/migration-06.xml

@@ -0,0 +1,259 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.06">
+    <title>Zend Framework 0.6</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 0.6 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.06.zend.controller">
+        <title>Zend_Controller</title>
+
+        <para>
+            The most basic usage of the <acronym>MVC</acronym> components has not changed; you can
+            still do each of the following:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+Zend_Controller_Front::run('/path/to/controllers');
+]]></programlisting>
+
+        <programlisting language="php"><![CDATA[
+/* -- create a router -- */
+$router = new Zend_Controller_RewriteRouter();
+$router->addRoute('user',
+                  'user/:username',
+                  array('controller' => 'user', 'action' => 'info')
+);
+
+/* -- set it in a controller -- */
+$ctrl = Zend_Controller_Front::getInstance();
+$ctrl->setRouter($router);
+
+/* -- set controller directory and dispatch -- */
+$ctrl->setControllerDirectory('/path/to/controllers');
+$ctrl->dispatch();
+]]></programlisting>
+
+        <para>
+            We encourage use of the Response object to aggregate content and
+            headers. This will allow for more flexible output format switching
+            (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>,
+            and then render the response using your own logic. A future version
+            of the front controller may enforce use of the response object via
+            output buffering.
+        </para>
+
+        <para>
+            There are many additional features that extend the existing <acronym>API</acronym>,
+            and these are noted in the documentation.
+        </para>
+
+        <para>
+            The main changes you will need to be aware of will be found when
+            subclassing the various components. Key amongst these are:
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    <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:
+                </para>
+
+                <itemizedlist>
+                    <listitem>
+                        <para>
+                            Set <methodname>throwExceptions()</methodname> in the front
+                            controller:
+                        </para>
+                        <programlisting language="php"><![CDATA[
+$front->throwExceptions(true);
+]]></programlisting>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            Set <methodname>renderExceptions()</methodname> in the response
+                            object:
+                        </para>
+                        <programlisting language="php"><![CDATA[
+$response->renderExceptions(true);
+$front->setResponse($response);
+$front->dispatch();
+
+// or:
+$front->returnResponse(true);
+$response = $front->dispatch();
+$response->renderExceptions(true);
+echo $response;
+]]></programlisting>
+                    </listitem>
+                </itemizedlist>
+            </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>
+                    <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</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>
+                            <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 <acronym>URL</acronym> parameters. This information is now
+                            available in the request object, and can be accessed
+                            as follows:
+                        </para>
+
+                        <programlisting language="php"><![CDATA[
+// Retrieve the requested controller name
+// Access used to be via: $this->_action->getControllerName().
+// The example below uses getRequest(), though you may also directly
+// access the $_request property; using getRequest() is recommended as
+// a parent class may override access to the request object.
+$controller = $this->getRequest()->getControllerName();
+
+// Retrieve the requested action name
+// Access used to be via: $this->_action->getActionName().
+$action = $this->getRequest()->getActionName();
+
+// Retrieve the request parameters
+// This hasn't changed; the _getParams() and _getParam() methods simply
+// proxy to the request object now.
+$params = $this->_getParams();
+// request 'foo' parameter, using 'default' as default value if not found
+$foo = $this->_getParam('foo', 'default');
+]]></programlisting>
+                    </listitem>
+
+                    <listitem>
+                        <para>
+                            <methodname>noRouteAction()</methodname> has been removed. The
+                            appropriate way to handle non-existent action
+                            methods should you wish to route them to a default
+                            action is using <methodname>__call()</methodname>:
+                        </para>
+
+                        <programlisting language="php"><![CDATA[
+public function __call($method, $args)
+{
+    // If an unmatched 'Action' method was requested, pass on to the
+    // default action method:
+    if ('Action' == substr($method, -6)) {
+        return $this->defaultAction();
+    }
+
+    throw new Zend_Controller_Exception('Invalid method called');
+}
+]]></programlisting>
+                    </listitem>
+                </itemizedlist>
+            </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>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-08.xml

@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.08">
+    <title>Zend Framework 0.8</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 0.8 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.08.zend.controller">
+        <title>Zend_Controller</title>
+
+        <para>
+            Per previous changes, the most basic usage of the <acronym>MVC</acronym> components
+            remains the same:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+Zend_Controller_Front::run('/path/to/controllers');
+]]></programlisting>
+
+        <para>
+            However, the directory structure underwent an overhaul, several
+            components were removed, and several others either renamed or added.
+            Changes include:
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    <classname>Zend_Controller_Router</classname> was removed in favor of
+                    the rewrite router.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <classname>Zend_Controller_RewriteRouter</classname> was renamed to
+                    <classname>Zend_Controller_Router_Rewrite</classname>, and promoted to
+                    the standard router shipped with the framework;
+                    <classname>Zend_Controller_Front</classname> will use it by default if
+                    no other router is supplied.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    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 <acronym>MVC</acronym>, and has support for <link
+                        linkend="zend.controller.modular">controller
+                        modules</link>.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <classname>Zend_Controller_Router_StaticRoute</classname> was renamed
+                    to <classname>Zend_Controller_Router_Route_Static</classname>.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <classname>Zend_Controller_Dispatcher</classname> was renamed
+                    <classname>Zend_Controller_Dispatcher_Standard</classname>.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <methodname>Zend_Controller_Action::_forward()</methodname>'s arguments
+                    have changed. The signature is now:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+final protected function _forward($action,
+                                  $controller = null,
+                                  $module = null,
+                                  array $params = null);
+]]></programlisting>
+
+                <para>
+                    <varname>$action</varname> is always required; if no controller is
+                    specified, an action in the current controller is assumed.
+                    <varname>$module</varname> is always ignored unless
+                    <varname>$controller</varname> is specified. Finally, any
+                    <varname>$params</varname> provided will be appended to the
+                    request object. If you do not require the controller or
+                    module, but still need to pass parameters, simply specify
+                    <constant>NULL</constant> for those values.
+                </para>
+            </listitem>
+        </itemizedlist>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-09.xml

@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.09">
+    <title>Zend Framework 0.9</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 0.9 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.09.zend.controller">
+        <title>Zend_Controller</title>
+
+        <para>
+            0.9.3 introduces <link
+                linkend="zend.controller.actionhelpers">action helpers</link>.
+            As part of this change, the following methods have been removed as
+            they are now encapsulated in the <link
+                linkend="zend.controller.actionhelpers.redirector">redirector
+                action helper</link>:
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    <methodname>setRedirectCode()</methodname>; use
+                    <methodname>Zend_Controller_Action_Helper_Redirector::setCode()</methodname>.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <methodname>setRedirectPrependBase()</methodname>; use
+                    <methodname>Zend_Controller_Action_Helper_Redirector::setPrependBase()</methodname>.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <methodname>setRedirectExit()</methodname>; use
+                    <methodname>Zend_Controller_Action_Helper_Redirector::setExit()</methodname>.
+                </para>
+            </listitem>
+        </itemizedlist>
+
+        <para>
+            Read the <link linkend="zend.controller.actionhelpers">action
+                helpers documentation</link> for more information on how to
+            retrieve and manipulate helper objects, and the <link
+                linkend="zend.controller.actionhelpers.redirector">redirector
+                helper documentation</link> for more information on setting
+            redirect options (as well as alternate methods for redirecting).
+        </para>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-10.xml

@@ -0,0 +1,299 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.10">
+    <title>Zend Framework 1.0</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 1.7 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.10.zend.controller">
+        <title>Zend_Controller</title>
+
+        <para>
+            The principal changes introduced in 1.0.0RC1 are the introduction of
+            and default enabling of the
+            <link
+                linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
+            plugin and the <link
+                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>
+            action helper. Please read the documentation to each thoroughly to
+            see how they work and what effect they may have on your
+            applications.
+        </para>
+
+        <para>
+            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 <property>noErrorHandler</property>:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$front->setParam('noErrorHandler', true);
+]]></programlisting>
+
+        <para>
+            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 <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
+            <classname>ViewRenderer</classname> in your front controller bootstrap prior
+            to dispatching:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+// Assuming $front is an instance of Zend_Controller_Front
+$front->setParam('noViewRenderer', true);
+]]></programlisting>
+
+        <para>
+            However, this is not a good long term strategy, as it means most
+            likely you'll be writing more code.
+        </para>
+
+        <para>
+            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
+            the following is happening, you'll need to make changes:
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>Calls to <command>$this->render();</command></para>
+            </listitem>
+            <listitem>
+                <para>Calls to <command>$this->_forward();</command></para>
+            </listitem>
+            <listitem>
+                <para>Calls to <command>$this->_redirect();</command></para>
+            </listitem>
+            <listitem>
+                <para>Calls to the <classname>Redirector</classname> action helper</para>
+            </listitem>
+        </itemizedlist>
+
+        <para>
+            The easiest change is to disable auto-rendering for that method:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$this->_helper->viewRenderer->setNoRender();
+]]></programlisting>
+
+        <para>
+            If you find that none of your action methods are rendering,
+            forwarding, or redirecting, you will likely want to put the above
+            line in your <methodname>preDispatch()</methodname> or <methodname>init()</methodname>
+            methods:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+public function preDispatch()
+{
+    // disable view script autorendering
+    $this->_helper->viewRenderer->setNoRender()
+    // .. do other things...
+}
+]]></programlisting>
+
+        <para>
+            If you are calling <methodname>render()</methodname>, and you're using <link
+                linkend="zend.controller.modular">the Conventional Modular
+                directory structure</link>, you'll want to change your code to
+            make use of autorendering:
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    If you're rendering multiple view scripts in a single
+                    action, you don't need to change a thing.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    If you're simply calling <methodname>render()</methodname> with no
+                    arguments, you can remove such lines.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    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
+                    <command>$this->_helper->viewRenderer();</command>.
+                </para>
+            </listitem>
+        </itemizedlist>
+
+        <para>
+            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
+            <classname>ViewRenderer</classname>. Please read the <link
+                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer
+                documentation</link> for information on these methods.
+        </para>
+
+        <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 <classname>ViewRenderer</classname> with this object. This can
+            be done easily at any time.
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    Prior to dispatching a front controller instance:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+// Assuming $view has already been defined
+$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
+Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
+]]></programlisting>
+            </listitem>
+
+            <listitem>
+                <para>
+                    Any time during the bootstrap process:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$viewRenderer =
+    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
+$viewRenderer->setView($view);
+]]></programlisting>
+            </listitem>
+        </itemizedlist>
+
+        <para>
+            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 <classname>ViewRenderer</classname>.
+        </para>
+
+        <para>
+            We encourage you to adapt your code to use the
+            <classname>ErrorHandler</classname> and <classname>ViewRenderer</classname> as they are
+            now core functionality.
+        </para>
+    </sect2>
+
+    <sect2 id="migration.10.zend.currency">
+        <title>Zend_Currency</title>
+
+        <para>
+            Creating an object of <classname>Zend_Currency</classname> has become simpler.
+            You no longer have to give a script or set it to <constant>NULL</constant>. The optional
+            script parameter is now an option which can be set through the
+            <methodname>setFormat()</methodname> method.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$currency = new Zend_Currency($currency, $locale);
+]]></programlisting>
+
+        <para>
+            The <methodname>setFormat()</methodname> method takes now an array of options. These
+            options are set permanently and override all previously set values. Also a new option
+            'precision' has been added. The following options have been refactored:
+        </para>
+
+        <itemizedlist mark='opencircle'>
+            <listitem>
+                <para>
+                    <emphasis>position</emphasis>:
+                    Replacement for the old 'rules' parameter.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>script</emphasis>:
+                    Replacement for the old 'script' parameter.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>format</emphasis>:
+                    Replacement for the old 'locale' parameter which does not
+                    set new currencies but only the number format.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>display</emphasis>:
+                    Replacement for the old 'rules' parameter.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>precision</emphasis>:
+                    New parameter.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>name</emphasis>:
+                    Replacement for the ole 'rules' parameter. Sets the full
+                    currencies name.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>currency</emphasis>:
+                    New parameter.
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>symbol</emphasis>:
+                    New parameter.
+                </para>
+            </listitem>
+        </itemizedlist>
+
+        <programlisting language="php"><![CDATA[
+$currency->setFormat(array $options);
+]]></programlisting>
+
+        <para>
+            The <methodname>toCurrency()</methodname> method no longer supports the optional
+            'script' and 'locale' parameters. Instead it takes an options array which
+            can contain the same keys as for the <methodname>setFormat()</methodname> method.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$currency->toCurrency($value, array $options);
+]]></programlisting>
+
+        <para>
+            The methods <methodname>getSymbol()</methodname>,
+            <methodname>getShortName()</methodname>, <methodname>getName()</methodname>,
+            <methodname>getRegionList()</methodname> and
+            <methodname>getCurrencyList()</methodname> are no longer static and can be called
+            from within the object. They return the set values of the object if no
+            parameter has been set.
+        </para>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/module_specs/Zend_Validate-Migration.xml → documentation/manual/en/ref/migration-110.xml

@@ -1,20 +1,62 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- Reviewed: no -->
-<sect1 id="zend.validate.migration">
-
-    <title>Migrating from previous versions</title>
+<sect1 id="migration.110">
+    <title>Zend Framework 1.10</title>
 
     <para>
-        The <acronym>API</acronym> of <classname>Zend_Validate</classname> has changed from time
-        to time. If you started to use <classname>Zend_Validate</classname> and its subcomponents
-        in earlier versions follow the guidelines below to migrate your scripts to
-        use the new <acronym>API</acronym>.
+        When upgrading from a previous release to Zend Framework 1.10 or higher you
+        should note the following migration notes.
     </para>
 
-    <sect2 id="zend.validate.migration.fromoneninetooneten">
-        <title>Migrating from 1.9 to 1.10 or newer</title>
-        <sect3 id="zend.validate.migration.fromoneninetooneten.selfwritten">
-            <title>Self written adapters</title>
+    <sect2 id="migration.110.zend.file.transfer">
+        <title>Zend_File_Transfer</title>
+        <sect3 id="migration.110.zend.file.transfer.mimetype">
+            <title>MimeType validation</title>
+
+            <para>
+                For security reasons we had to turn off the default fallback mechanism of the
+                <classname>MimeType</classname>, <classname>ExcludeMimeType</classname>,
+                <classname>IsCompressed</classname> and <classname>IsImage</classname> validators.
+                This means, that if the <emphasis>fileInfo</emphasis> or
+                <emphasis>magicMime</emphasis> extensions can not be found, the validation will
+                always fail.
+            </para>
+
+            <para>
+                If you are in need of validation by using the <acronym>HTTP</acronym> fields which
+                are provided by the user then you can turn on this feature by using the
+                <methodname>enableHeaderCheck()</methodname> method.
+            </para>
+
+            <note>
+                <title>Security hint</title>
+
+                <para>
+                    You should note that relying on the <acronym>HTTP</acronym> fields, which are
+                    provided by your user, is a security risk. They can easily be changed and could
+                    allow your user to provide a malcious file.
+                </para>
+            </note>
+
+            <example id="migration.110.zend.file.transfer.example">
+                <title>Allow the usage of the HTTP fields</title>
+
+                <programlisting language="php"><![CDATA[
+// at initiation
+$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);
+
+// or afterwards
+$valid->enableHeaderCheck();
+]]></programlisting>
+        </example>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.110.zend.validate">
+        <title>Zend_Validate</title>
+
+        <sect3 id="migration.110.zend.validate.selfwritten">
+            <title>Self written validators</title>
 
             <para>
                 When setting returning a error from within a self written validator you have to
@@ -60,7 +102,7 @@ My_Validator extends Zend_Validate_Abstract
 ]]></programlisting>
         </sect3>
 
-        <sect3 id="zend.validate.migration.fromoneninetooneten.datevalidator">
+        <sect3 id="migration.110.zend.validate.datevalidator">
             <title>Simplification in date validator</title>
 
             <para>
@@ -72,7 +114,7 @@ My_Validator extends Zend_Validate_Abstract
             </para>
         </sect3>
 
-        <sect3 id="zend.validate.migration.fromoneninetooneten.barcodevalidator">
+        <sect3 id="migration.110.zend.validate.barcodevalidator">
             <title>Fixes in Alpha, Alnum and Barcode validator</title>
 
             <para>
@@ -88,7 +130,7 @@ My_Validator extends Zend_Validate_Abstract
                 then you will have to change them. The following table shows you the changed values:
             </para>
 
-            <table id="zend.validate.migration.fromoneninetooneten.barcodevalidator.table">
+            <table id="migration.110.zend.validate.barcodevalidator.table">
                 <title>Available Validation Messages</title>
                 <tgroup cols="3">
                     <thead>
@@ -148,3 +190,6 @@ My_Validator extends Zend_Validate_Abstract
         </sect3>
     </sect2>
 </sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-15.xml

@@ -0,0 +1,138 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.15">
+    <title>Zend Framework 1.5</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 1.5 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.15.zend.controller">
+        <title>Zend_Controller</title>
+
+        <para>
+            Though most basic functionality remains the same, and all documented
+            functionality remains the same, there is one particular
+            <emphasis>undocumented</emphasis> "feature" that has changed.
+        </para>
+
+        <para>
+            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 <acronym>PHP</acronym>
+            functions are not case sensitive, you <emphasis>could</emphasis>
+            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
+            <acronym>PHP</acronym>, both will execute the same method.
+        </para>
+
+        <para>
+            This causes issues with the ViewRenderer when resolving view
+            scripts. The canonical, documented way is that all word separators
+            are converted to dashes, and the words lowercased. This creates
+            a semantic tie between the actions and view scripts, and the
+            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 -- <filename>camelcased.phtml</filename> instead of
+            <filename>camel-cased.phtml</filename>.
+        </para>
+
+        <para>
+            Some developers relied on this "feature", which was never intended.
+            Several changes in the 1.5.0 tree, however, made it so that the
+            ViewRenderer no longer resolves these paths; the semantic tie is now
+            enforced. First among these, the dispatcher now enforces case
+            sensitivity in action names. What this means is that referring to
+            your actions on the url using camelCasing will no longer resolve to
+            the same method as using word separators (i.e., 'camel-casing').
+            This leads to the ViewRenderer now only honoring the word-separated
+            actions when resolving view scripts.
+        </para>
+
+        <para>
+            If you find that you were relying on this "feature", you have several
+            options:
+        </para>
+
+        <itemizedlist>
+            <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>
+
+            <listitem>
+                <para>
+                    Second best option: The ViewRenderer now delegates view
+                    script resolution to <classname>Zend_Filter_Inflector</classname>; you
+                    can modify the rules of the inflector to no longer separate
+                    the words of an action with a dash:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$viewRenderer =
+    Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
+$inflector = $viewRenderer->getInflector();
+$inflector->setFilterRule(':action', array(
+    new Zend_Filter_PregReplace(
+        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
+        ''
+    ),
+    'StringToLower'
+));
+]]></programlisting>
+
+                <para>
+                    The above code will modify the inflector to no longer
+                    separate the words with dash; you may also want to remove
+                    the 'StringToLower' filter if you <emphasis>do</emphasis>
+                    want the actual view script names camelCased as well.
+                </para>
+
+                <para>
+                    If renaming your view scripts would be too tedious or time
+                    consuming, this is your best option until you can find the
+                    time to do so.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    Least desirable option: You can force the dispatcher to
+                    dispatch camelCased action names with a new front controller
+                    flag, <property>useCaseSensitiveActions</property>:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$front->setParam('useCaseSensitiveActions', true);
+]]></programlisting>
+
+                <para>
+                    This will allow you to use camelCasing on the url and still
+                    have it resolve to the same action as when you use word
+                    separators. However, this will mean that the original issues
+                    will cascade on through; you will likely need to use the
+                    second option above in addition to this for things to work
+                    at all reliably.
+                </para>
+
+                <para>
+                    Note, also, that usage of this flag will raise a notice that
+                    this usage is deprecated.
+                </para>
+            </listitem>
+        </itemizedlist>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-16.xml

@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.16">
+    <title>Zend Framework 1.6</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 1.6 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.16.zend.controller">
+        <title>Zend_Controller</title>
+
+        <sect3 id="migration.16.zend.controller.dispatcher">
+            <title>Dispatcher Interface Changes</title>
+
+            <para>
+                Users brought to our attention the fact that
+                <classname>Zend_Controller_Front</classname> and
+                <classname>Zend_Controller_Router_Route_Module</classname> were each
+                using methods of the dispatcher that were not in the dispatcher
+                interface. We have now added the following three methods to
+                ensure that custom dispatchers will continue to work with the
+                shipped implementations:
+            </para>
+
+            <itemizedlist>
+                <listitem><para>
+                    <methodname>getDefaultModule()</methodname>: should return the name of
+                    the default module.
+                </para></listitem>
+
+                <listitem><para>
+                    <methodname>getDefaultControllerName()</methodname>: should return the
+                    name of the default controller.
+                </para></listitem>
+
+                <listitem><para>
+                    <methodname>getDefaultAction()</methodname>: should return the
+                    name of the default action.
+                </para></listitem>
+            </itemizedlist>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.16.zend.file.transfer">
+        <title>Zend_File_Transfer</title>
+        <sect3 id="migration.16.zend.file.transfer.validators">
+            <title>Changes when using validators</title>
+
+            <para>
+                As noted by users, the validators from <classname>Zend_File_Transfer</classname>
+                do not work the same way like the default ones from
+                <classname>Zend_Form</classname>. <classname>Zend_Form</classname> allows the usage
+                of a <varname>$breakChainOnFailure</varname> parameter which breaks the validation
+                for all further validators when an validation error has occurred.
+            </para>
+
+            <para>
+                So we added this parameter also to all existing validators from
+                <classname>Zend_File_Transfer</classname>.
+            </para>
+
+            <itemizedlist>
+                <listitem><para>
+                    Old method <acronym>API</acronym>: <methodname>addValidator($validator, $options, $files)</methodname>.
+                </para></listitem>
+
+                <listitem><para>
+                    New method <acronym>API</acronym>: <methodname>addValidator($validator,
+                    $breakChainOnFailure, $options, $files)</methodname>.
+                </para></listitem>
+            </itemizedlist>
+
+            <para>
+                To migrate your scripts to the new <acronym>API</acronym>, simply add a <constant>FALSE</constant>
+                after defining the wished validator.
+            </para>
+
+            <example id="migration.16.zend.file.transfer.example">
+                <title>How to change your file validators from 1.6.1 to 1.6.2</title>
+
+                <programlisting language="php"><![CDATA[
+// Example for 1.6.1
+$upload = new Zend_File_Transfer_Adapter_Http();
+$upload->addValidator('FilesSize', array('1B', '100kB'));
+
+// Same example for 1.6.2 and newer
+// Note the added boolean false
+$upload = new Zend_File_Transfer_Adapter_Http();
+$upload->addValidator('FilesSize', false, array('1B', '100kB'));
+]]></programlisting>
+        </example>
+        </sect3>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/module_specs/Zend_File_Transfer-Migration.xml → documentation/manual/en/ref/migration-17.xml

@@ -1,63 +1,45 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- Reviewed: no -->
-<sect1 id="zend.file.transfer.migration">
-
-    <title>Migrating from previous versions</title>
+<sect1 id="migration.17">
+    <title>Zend Framework 1.7</title>
 
     <para>
-        The <acronym>API</acronym> of <classname>Zend_File_Transfer</classname> has changed from time to time.
-        If you started to use <classname>Zend_File_Transfer</classname> and it's subcomponents
-        in earlier versions follow the guidelines below to migrate your scripts to
-        use the new <acronym>API</acronym>.
+        When upgrading from a previous release to Zend Framework 1.7 or higher you
+        should note the following migration notes.
     </para>
 
-    <sect2 id="zend.file.transfer.migration.fromonenineonetooneten">
-        <title>Migrating from 1.9 to 1.10 or newer</title>
-        <sect3 id="zend.file.transfer.migration.fromonenineonetooneten.mimetype">
-            <title>MimeType validation</title>
+    <sect2 id="migration.17.zend.controller">
+        <title>Zend_Controller</title>
 
-            <para>
-                For security reasons we had to turn off the default fallback mechanism of the
-                <classname>MimeType</classname>, <classname>ExcludeMimeType</classname>,
-                <classname>IsCompressed</classname> and <classname>IsImage</classname> validators.
-                This means, that if the <emphasis>fileInfo</emphasis> or
-                <emphasis>magicMime</emphasis> extensions can not be found, the validation will
-                always fail.
-            </para>
+        <sect3 id="migration.17.zend.controller.dispatcher">
+            <title>Dispatcher Interface Changes</title>
 
             <para>
-                If you are in need of validation by using the <acronym>HTTP</acronym> fields which
-                are provided by the user then you can turn on this feature by using the
-                <methodname>enableHeaderCheck()</methodname> method.
+                Users brought to our attention the fact that
+                <classname>Zend_Controller_Action_Helper_ViewRenderer</classname> were
+                using a method of the dispatcher abstract class that was not in
+                the dispatcher interface. We have now added the following method to
+                ensure that custom dispatchers will continue to work with the
+                shipped implementations:
             </para>
 
-            <note>
-                <title>Security hint</title>
-
-                <para>
-                    You should note that relying on the <acronym>HTTP</acronym> fields, which are
-                    provided by your user, is a security risk. They can easily be changed and could
-                    allow your user to provide a malcious file.
-                </para>
-            </note>
-
-            <example id="zend.file.transfer.migration.fromonenineonetooneten.example">
-                <title>Allow the usage of the HTTP fields</title>
-
-                <programlisting language="php"><![CDATA[
-// at initiation
-$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);
-
-// or afterwards
-$valid->enableHeaderCheck();
-]]></programlisting>
-        </example>
+            <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>
+            </itemizedlist>
         </sect3>
     </sect2>
 
-    <sect2 id="zend.file.transfer.migration.fromonesixtooneseven">
-        <title>Migrating from 1.6 to 1.7 or newer</title>
-        <sect3 id="zend.file.transfer.migration.fromonesixtooneseven.validators">
+    <sect2 id="migration.17.zend.file.transfer">
+        <title>Zend_File_Transfer</title>
+
+        <sect3 id="migration.17.zend.file.transfer.validators">
             <title>Changes when using filters and validators</title>
 
             <para>
@@ -78,7 +60,7 @@ $valid->enableHeaderCheck();
                 usage of the parameters.
             </para>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.rename">
+            <sect4 id="migration.17.zend.file.transfer.validators.rename">
                 <title>Filter: Rename</title>
 
                 <itemizedlist>
@@ -96,7 +78,7 @@ $valid->enableHeaderCheck();
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.rename.example">
+                <example id="migration.17.zend.file.transfer.validators.rename.example">
                     <title>Changes for the rename filter from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -115,7 +97,7 @@ $upload->addFilter('Rename',
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.count">
+            <sect4 id="migration.17.zend.file.transfer.validators.count">
                 <title>Validator: Count</title>
 
                 <itemizedlist>
@@ -131,7 +113,7 @@ $upload->addFilter('Rename',
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.count.example">
+                <example id="migration.17.zend.file.transfer.validators.count.example">
                     <title>Changes for the count validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -150,7 +132,7 @@ $upload->addValidator('Count',
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.extension">
+            <sect4 id="migration.17.zend.file.transfer.validators.extension">
                 <title>Validator:Extension</title>
 
                 <itemizedlist>
@@ -168,7 +150,7 @@ $upload->addValidator('Count',
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.extension.example">
+                <example id="migration.17.zend.file.transfer.validators.extension.example">
                     <title>Changes for the extension validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -187,7 +169,7 @@ $upload->addValidator('Extension',
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.filessize">
+            <sect4 id="migration.17.zend.file.transfer.validators.filessize">
                 <title>Validator: FilesSize</title>
 
                 <itemizedlist>
@@ -214,7 +196,7 @@ $upload->addValidator('Extension',
                     <methodname>setUseByteString()</methodname> method.
                 </para>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.filessize.example">
+                <example id="migration.17.zend.file.transfer.validators.filessize.example">
                     <title>Changes for the filessize validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -240,7 +222,7 @@ $upload->setUseByteSting(true); // set flag
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.hash">
+            <sect4 id="migration.17.zend.file.transfer.validators.hash">
                 <title>Validator: Hash</title>
 
                 <itemizedlist>
@@ -257,7 +239,7 @@ $upload->setUseByteSting(true); // set flag
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.hash.example">
+                <example id="migration.17.zend.file.transfer.validators.hash.example">
                     <title>Changes for the hash validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -276,7 +258,7 @@ $upload->addValidator('Hash',
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.imagesize">
+            <sect4 id="migration.17.zend.file.transfer.validators.imagesize">
                 <title>Validator: ImageSize</title>
 
                 <itemizedlist>
@@ -295,7 +277,7 @@ $upload->addValidator('Hash',
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.imagesize.example">
+                <example id="migration.17.zend.file.transfer.validators.imagesize.example">
                     <title>Changes for the imagesize validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -316,7 +298,7 @@ $upload->addValidator('ImageSize',
                 </example>
             </sect4>
 
-            <sect4 id="zend.file.transfer.migration.fromonesixtooneseven.validators.size">
+            <sect4 id="migration.17.zend.file.transfer.validators.size">
                 <title>Validator: Size</title>
 
                 <itemizedlist>
@@ -334,7 +316,7 @@ $upload->addValidator('ImageSize',
                     </para></listitem>
                 </itemizedlist>
 
-                <example id="zend.file.transfer.migration.fromonesixonetooneseven.validators.size.example">
+                <example id="migration.17.zend.file.transfer.validators.size.example">
                     <title>Changes for the size validator from 1.6 to 1.7</title>
 
                     <programlisting language="php"><![CDATA[
@@ -356,54 +338,235 @@ $upload->addValidator('Size',
         </sect3>
     </sect2>
 
-    <sect2 id="zend.file.transfer.migration.fromonesixonetoonesixtwo">
-        <title>Migrating from 1.6.1 to 1.6.2 or newer</title>
-        <sect3 id="zend.file.transfer.migration.fromonesixonetoonesixtwo.validators">
-            <title>Changes when using validators</title>
+    <sect2 id="migration.17.zend.locale">
+        <title>Zend_Locale</title>
+
+        <sect3 id="migration.17.zend.locale.islocale">
+            <title>Changes when using isLocale()</title>
 
             <para>
-                As noted by users, the validators from <classname>Zend_File_Transfer</classname>
-                do not work the same way like the default ones from
-                <classname>Zend_Form</classname>. <classname>Zend_Form</classname> allows the usage
-                of a <varname>$breakChainOnFailure</varname> parameter which breaks the validation
-                for all further validators when an validation error has occurred.
+                According to the coding standards isLocale() had to be changed to return
+                a boolean. In previous releases a string was returned on success. For
+                release 1.7 a compatibility mode has been added which allows to use the
+                old behaviour of a returned string, but it triggers a user warning to
+                mention you to change to the new behaviour. The rerouting which the old
+                behaviour of isLocale() could have done is no longer neccessary as all
+                I18N will now process a rerouting themself.
             </para>
 
             <para>
-                So we added this parameter also to all existing validators from
-                <classname>Zend_File_Transfer</classname>.
+                To migrate your scripts to the new <acronym>API</acronym>, simply use the method as shown below.
             </para>
 
-            <itemizedlist>
-                <listitem><para>
-                    Old method <acronym>API</acronym>: <methodname>addValidator($validator, $options, $files)</methodname>.
-                </para></listitem>
-
-                <listitem><para>
-                    New method <acronym>API</acronym>: <methodname>addValidator($validator,
-                    $breakChainOnFailure, $options, $files)</methodname>.
-                </para></listitem>
-            </itemizedlist>
+            <example id="migration.17.zend.locale.islocale.example">
+                <title>How to change isLocale() from 1.6 to 1.7</title>
+
+                <programlisting language="php"><![CDATA[
+// Example for 1.6
+if ($locale = Zend_Locale::isLocale($locale)) {
+    // do something
+}
+
+// Same example for 1.7
+
+// You should change the compatiblity mode to prevent user warnings
+// But you can do this in your bootstrap
+Zend_Locale::$compatibilityMode = false;
+
+if (Zend_Locale::isLocale($locale)) {
+}
+]]></programlisting>
+
+                <para>
+                    Note that you can use the second parameter to see if the locale is correct without
+                    processing a rerouting.
+                </para>
+
+                <programlisting language="php"><![CDATA[
+// Example for 1.6
+if ($locale = Zend_Locale::isLocale($locale, false)) {
+    // do something
+}
+
+// Same example for 1.7
+
+// You should change the compatiblity mode to prevent user warnings
+// But you can do this in your bootstrap
+Zend_Locale::$compatibilityMode = false;
+
+if (Zend_Locale::isLocale($locale, false)) {
+    if (Zend_Locale::isLocale($locale, true)) {
+        // no locale at all
+    }
+
+    // original string is no locale but can be rerouted
+}
+]]></programlisting>
+
+            </example>
+        </sect3>
+
+        <sect3 id="migration.17.zend.locale.islocale.getdefault">
+            <title>Changes when using getDefault()</title>
 
             <para>
-                To migrate your scripts to the new <acronym>API</acronym>, simply add a <constant>FALSE</constant>
-                after defining the wished validator.
+                The meaning of the getDefault() method has been change due to the fact that we
+                integrated a framework locale which can be set with setDefault(). It does no
+                longer return the locale chain but only the set framework locale.
             </para>
 
-            <example id="zend.file.transfer.migration.fromonesixonetoonesixtwo.example">
-                <title>How to change your file validators from 1.6.1 to 1.6.2</title>
+            <para>
+                To migrate your scripts to the new <acronym>API</acronym>, simply use the method as shown below.
+            </para>
+
+            <example id="migration.17.zend.locale.islocale.getdefault.example">
+                <title>How to change getDefault() from 1.6 to 1.7</title>
 
                 <programlisting language="php"><![CDATA[
-// Example for 1.6.1
-$upload = new Zend_File_Transfer_Adapter_Http();
-$upload->addValidator('FilesSize', array('1B', '100kB'));
+// Example for 1.6
+$locales = $locale->getDefault(Zend_Locale::BROWSER);
 
-// Same example for 1.6.2 and newer
-// Note the added boolean false
-$upload = new Zend_File_Transfer_Adapter_Http();
-$upload->addValidator('FilesSize', false, array('1B', '100kB'));
+// Same example for 1.7
+
+// You should change the compatiblity mode to prevent user warnings
+// But you can do this in your bootstrap
+Zend_Locale::$compatibilityMode = false;
+
+$locale = Zend_Locale::getOrder(Zend_Locale::BROWSER);
+]]></programlisting>
+
+                <para>
+                    Note that the second parameter of the old getDefault() implementation is not
+                    available anymore, but the returned values are the same.
+                </para>
+            </example>
+
+            <note>
+                <para>
+                    Per default the old behaviour is still active, but throws a user warning.
+                    When you have changed your code to the new behaviour you should also change
+                    the compatibility mode to false so that no warning is thrown anymore.
+                </para>
+            </note>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.17.zend.translate">
+        <title>Zend_Translate</title>
+
+        <sect3 id="migration.17.zend.translate.languages">
+            <title>Setting languages</title>
+
+            <para>
+                When using automatic detection of languages, or setting languages manually
+                to <classname>Zend_Translate</classname> you may have mentioned that from time to time a
+                notice is thrown about not added or empty translations. In some previous
+                release also an exception was raised in some cases.
+            </para>
+
+            <para>
+                The reason is, that when a user requests a non existing language, you
+                have no simple way to detect what's going wrong. So we added those
+                notices which show up in your log and tell you that the user requested
+                a language which you do not support. Note that the code, even when
+                we trigger such an notice, keeps working without problems.
+            </para>
+
+            <para>
+                But when you use a own error or exception handler, like xdebug, you
+                will get all notices returned, even if this was not your intention.
+                This is due to the fact that these handlers override all settings
+                from within <acronym>PHP</acronym>.
+            </para>
+
+            <para>
+                To get rid of these notices you can simply set the new option
+                'disableNotices' to true. It defaults to false.
+            </para>
+
+            <example id="migration.17.zend.translate.example">
+                <title>Setting languages without getting notices</title>
+
+                <para>
+                    Let's assume that we have 'en' available and our user requests
+                    'fr' which is not in our portfolio of translated languages.
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$language = new Zend_Translate('gettext',
+                               '/path/to/translations',
+                               'auto');
+]]></programlisting>
+
+                <para>
+                    In this case we will get an notice about a not available language 'fr'.
+                    Simply add the option and the notices will be disabled.
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$language = new Zend_Translate('gettext',
+                               '/path/to/translations',
+                               'auto',
+                               array('disableNotices' => true));
+]]></programlisting>
+
+            </example>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.17.zend.view">
+        <title>Zend_View</title>
+
+        <note>
+            <para>
+                The API changes within <classname>Zend_View</classname> are only
+                notable for you when you are upgrading to release 1.7.5 or higher.
+            </para>
+        </note>
+
+        <para>
+            Prior to the 1.7.5 release, the Zend Framework team was notified of
+            a potential Local File Inclusion (LFI) vulnerability in the
+            <methodname>Zend_View::render()</methodname> method. Prior to 1.7.5, the method
+            allowed, by default, the ability to specify view scripts that
+            included parent directory notation (e.g., "../" or "..\"). This
+            opens the possibility for an LFI attack if unfiltered user input is
+            passed to the <methodname>render()</methodname> method:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+// Where $_GET['foobar'] = '../../../../etc/passwd'
+echo $view->render($_GET['foobar']); // LFI inclusion
+]]></programlisting>
+
+        <para>
+            <classname>Zend_View</classname> now by default raises an exception when such
+            a view script is requested.
+        </para>
+
+        <sect3 id="migration.17.zend.view.disabling">
+            <title>Disabling LFI protection for the render() method</title>
+
+            <para>
+                Since a number of developers reported that they were using such
+                notation within their applications that was <emphasis>not</emphasis>
+                the result of user input, a special flag was created to allow
+                disabling the default protection. You have two methods for doing so:
+                by passing the 'lfiProtectionOn' key to the constructor options, or
+                by explicitly calling the <methodname>setLfiProtection()</methodname> method.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+// Disabling via constructor
+$view = new Zend_View(array('lfiProtectionOn' => false));
+
+// Disabling via exlicit method call:
+$view = new Zend_View();
+$view->setLfiProtection(false);
 ]]></programlisting>
-        </example>
         </sect3>
     </sect2>
 </sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-18.xml

@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.18">
+    <title>Zend Framework 1.8</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 1.8 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.18.zend.controller">
+        <title>Zend_Controller</title>
+
+        <sect3 id="migration.18.zend.controller.router">
+            <title>Standard Route Changes</title>
+
+            <para>
+                As translated segments were introduced into the new standard
+                route, the '<emphasis>@</emphasis>' character is now a special character
+                in the beginning of a route segment. To be able to use it in a
+                static segment, you must escape it by prefixing it with second
+                '<emphasis>@</emphasis>' character. The same rule now applies for the
+                '<emphasis>:</emphasis>' character.
+            </para>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.18.zend.locale">
+        <title>Zend_Locale</title>
+
+        <sect3 id="migration.18.zend.locale.defaultcaching">
+            <title>Default caching</title>
+
+            <para>
+                As with Zend Framework 1.8 a default caching was added. The reason behind this
+                change was, that most users had performance problems but did not add caching at
+                all. As the I18n core is a bottleneck when no caching is used we decided to add
+                a default caching when no cache has been set to <classname>Zend_Locale</classname>.
+            </para>
+
+            <para>
+                Sometimes it is still wanted to prevent caching at all even if this decreases
+                performance. To do so you can simply disable caching by using the
+                <methodname>disableCache()</methodname> method.
+            </para>
+
+            <example id="migration.18.zend.locale.defaultcaching.example">
+                <title>Disabling default caching</title>
+
+                <programlisting language="php"><![CDATA[
+Zend_Locale::disableCache(true);
+]]></programlisting>
+            </example>
+        </sect3>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-19.xml

@@ -0,0 +1,266 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.19">
+    <title>Zend Framework 1.9</title>
+
+    <para>
+        When upgrading from a previous release to Zend Framework 1.9 or higher you
+        should note the following migration notes.
+    </para>
+
+    <sect2 id="migration.19.zend.filter">
+        <title>Zend_Filter</title>
+
+        <para>
+            Prior to the 1.9 release, <classname>Zend_Filter</classname> allowed
+            the usage of the static <methodname>get()</methodname> method. As with
+            release 1.9 this method has been renamed to
+            <methodname>filterStatic()</methodname> to be more descriptive. The
+            old <methodname>get()</methodname> method is marked as deprecated.
+        </para>
+    </sect2>
+
+    <sect2 id="migration.19.zend.http.client">
+        <title>Zend_Http_Client</title>
+
+        <sect3 id="migration.19.zend.http.client.fileuploadsarray">
+            <title>Changes to internal uploaded file information storage</title>
+
+            <para>
+                In version 1.9 of Zend Framework, there has been a change in the way
+                <classname>Zend_Http_Client</classname> internally stores information about
+                files to be uploaded, set using the <methodname>Zend_Http_Client::setFileUpload()</methodname>
+                method.
+            </para>
+
+            <para>
+                This change was introduced in order to allow multiple files to be uploaded
+                with the same form name, as an array of files. More information about this issue
+                can be found in <ulink url="http://framework.zend.com/issues/browse/ZF-5744">this bug report</ulink>.
+            </para>
+
+            <example id="migration.19.zend.http.client.fileuploadsarray.example">
+                <title>Internal storage of uploaded file information</title>
+
+                <programlisting language="php"><![CDATA[
+// Upload two files with the same form element name, as an array
+$client = new Zend_Http_Client();
+$client->setFileUpload('file1.txt',
+                       'userfile[]',
+                       'some raw data',
+                       'text/plain');
+$client->setFileUpload('file2.txt',
+                       'userfile[]',
+                       'some other data',
+                       'application/octet-stream');
+
+// In Zend Framework 1.8 or older, the value of
+// the protected member $client->files is:
+// $client->files = array(
+//     'userfile[]' => array('file2.txt',
+                             'application/octet-stream',
+                             'some other data')
+// );
+
+// In Zend Framework 1.9 or newer, the value of $client->files is:
+// $client->files = array(
+//     array(
+//         'formname' => 'userfile[]',
+//         'filename' => 'file1.txt,
+//         'ctype'    => 'text/plain',
+//         'data'     => 'some raw data'
+//     ),
+//     array(
+//         'formname' => 'userfile[]',
+//         'filename' => 'file2.txt',
+//         'formname' => 'application/octet-stream',
+//         'formname' => 'some other data'
+//     )
+// );
+]]></programlisting>
+            </example>
+
+            <para>
+                As you can see, this change permits the usage of the same form element name with
+                more than one file - however, it introduces a subtle backwards-compatibility change
+                and as such should be noted.
+            </para>
+        </sect3>
+
+        <sect3 id="migration.19.zend.http.client.getparamsrecursize">
+            <title>Deprecation of Zend_Http_Client::_getParametersRecursive()</title>
+
+            <para>
+                Starting from version 1.9, the protected method <methodname>_getParametersRecursive()</methodname>
+                is no longer used by <classname>Zend_Http_Client</classname> and is deprecated.
+                Using it will cause an E_NOTICE message to be emitted by <acronym>PHP</acronym>.
+            </para>
+
+            <para>
+                If you subclass <classname>Zend_Http_Client</classname> and call this method, you
+                should look into using the <methodname>Zend_Http_Client::_flattenParametersArray()</methodname>
+                static method instead.
+            </para>
+
+            <para>
+                Again, since this <classname>_getParametersRecursive</classname> is a protected method,
+                this change will only affect users who subclass <classname>Zend_Http_Client</classname>.
+            </para>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.19.zend.locale">
+        <title>Zend_Locale</title>
+
+        <sect3 id="migration.19.zend.locale.depreciated">
+            <title>Depreciated methods</title>
+
+            <para>
+                Some specialized translation methods have been depreciated because they duplicate
+                existing behaviour. Note that the old methods will still work, but a user notice is
+                triggered which describes the new call. The methods will be erased with 2.0.
+                See the following list for old and new method call.
+            </para>
+
+            <table id="migration.19.zend.locale.depreciated.table-1">
+                <title>List of measurement types</title>
+
+                <tgroup cols="2">
+                    <thead>
+                        <row>
+                            <entry>Old call</entry>
+                            <entry>New call</entry>
+                        </row>
+                    </thead>
+                    <tbody>
+                        <row>
+                            <entry>getLanguageTranslationList($locale)</entry>
+                            <entry>getTranslationList('language', $locale)</entry>
+                        </row>
+                        <row>
+                            <entry>getScriptTranslationList($locale)</entry>
+                            <entry>getTranslationList('script', $locale)</entry>
+                        </row>
+                        <row>
+                            <entry>getCountryTranslationList($locale)</entry>
+                            <entry>getTranslationList('territory', $locale, 2)</entry>
+                        </row>
+                        <row>
+                            <entry>getTerritoryTranslationList($locale)</entry>
+                            <entry>getTranslationList('territory', $locale, 1)</entry>
+                        </row>
+                        <row>
+                            <entry>getLanguageTranslation($value, $locale)</entry>
+                            <entry>getTranslation($value, 'language', $locale)</entry>
+                        </row>
+                        <row>
+                            <entry>getScriptTranslation($value, $locale)</entry>
+                            <entry>getTranslation($value, 'script', $locale)</entry>
+                        </row>
+                        <row>
+                            <entry>getCountryTranslation($value, $locale)</entry>
+                            <entry>getTranslation($value, 'country', $locale)</entry>
+                        </row>
+                        <row>
+                            <entry>getTerritoryTranslation($value, $locale)</entry>
+                            <entry>getTranslation($value, 'territory', $locale)</entry>
+                        </row>
+                    </tbody>
+                </tgroup>
+            </table>
+        </sect3>
+    </sect2>
+
+    <sect2 id="migration.19.zend.view.helper.navigation">
+        <title>Zend_View_Helper_Navigation</title>
+
+        <para>
+            Prior to the 1.9 release, the menu helper
+            (<classname>Zend_View_Helper_Navigation_Menu</classname>) did not
+            render sub menus correctly. When the <code>onlyActiveBranch</code>
+            was <constant>TRUE</constant> and the option <code>renderParents</code>
+            <constant>FALSE</constant>, nothing would be rendered if the deepest active
+            page was at a depth lower than the <code>minDepth</code> option.
+        </para>
+
+        <para>
+            In simpler words; if <code>minDepth</code> was set to <code>1</code>
+            and the active page was at one of the first level pages, nothing
+            would be rendered, as the following example shows.
+        </para>
+
+        <para>
+            Consider the following container setup:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+<?php
+$container = new Zend_Navigation(array(
+    array(
+        'label' => 'Home',
+        'uri'   => '#'
+    ),
+    array(
+        'label'  => 'Products',
+        'uri'    => '#',
+        'active' => true,
+        'pages'  => array(
+            array(
+                'label' => 'Server',
+                'uri'   => '#'
+            ),
+            array(
+                'label' => 'Studio',
+                'uri'   => '#'
+            )
+        )
+    ),
+    array(
+        'label' => 'Solutions',
+        'uri'   => '#'
+    )
+));
+]]></programlisting>
+
+        <para>
+            The following code is used in a view script:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+<?php echo $this->navigation()->menu()->renderMenu($container, array(
+    'minDepth'         => 1,
+    'onlyActiveBranch' => true,
+    'renderParents'    => false
+)); ?>
+]]></programlisting>
+
+        <para>
+            Before release 1.9, the code snippet above would output nothing.
+        </para>
+
+        <para>
+            Since release 1.9, the <methodname>_renderDeepestMenu()</methodname> method in
+            <classname>Zend_View_Helper_Navigation_Menu</classname> will accept
+            active pages at one level below <code>minDepth</code>, as long as
+            the page has children.
+        </para>
+
+        <para>
+            The same code snippet will now output the following:
+        </para>
+
+        <programlisting language="html"><![CDATA[
+<ul class="navigation">
+    <li>
+        <a href="#">Server</a>
+    </li>
+    <li>
+        <a href="#">Studio</a>
+    </li>
+</ul>
+]]></programlisting>
+    </sect2>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/migration-introduction.xml

@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
+<sect1 id="migration.introduction">
+    <title>Introduction</title>
+
+    <para>
+        When you are working with Zend Framework for a longer time, then you may
+        want to upgrade to new releases as new features are integrated and found
+        bugs are fixed.
+    </para>
+
+    <para>
+        We at Zend Framework try to prevent possible problems which you may have
+        when you are in need to do a upgrade. Backwards compatibility is one of our
+        main goals.
+    </para>
+
+    <para>
+        Still, from time to time, it is not possible or even necessary to make
+        changes which have effect on your code, to prevent or solve other problems.
+        To help you to detect possible changes you may need to do when upgrading
+        to a new Zend Framework release you should carefully read this section.
+    </para>
+
+    <para>
+        Below you will find informations about all known changes which can have
+        effect on your code and examples for you about necessary changes you
+        have to do when doing an upgrade.
+    </para>
+</sect1>
+<!--
+vim:se ts=4 sw=4 et:
+-->

documentation/manual/en/ref/requirements-php-extensions-table.xml

@@ -1337,19 +1337,25 @@
                 <entry>---</entry>
             </row>
             <row>
-                <entry>
+                <entry morerows="1" valign="middle">
                     <emphasis>
                         <ulink
                             url="http://www.php.net/manual/en/ref.zlib.php">zlib</ulink>
                     </emphasis>
                 </entry>
-                <entry>Hard</entry>
+                <entry morerows="1" valign="middle">Hard</entry>
                 <entry>
                     <ulink
                         url="http://framework.zend.com/manual/en/zend.pdf.html">
                         <classname>Zend_Pdf</classname>
                     </ulink>
                 </entry>
+                <entry>
+                    <ulink
+                        url="http://framework.zend.com/manual/en/zend.filter.set.compress.html">
+                        <classname>Zend_Filter_Compress</classname>
+                    </ulink>
+                </entry>
             </row>
         </tbody>
     </tgroup>

documentation/manual/en/ref/requirements-zendcomponents-table.xml

@@ -378,7 +378,7 @@
                 <entry>upload_extension</entry>
             </row>
             <row>
-                <entry>
+                <entry morerows="1" valign="middle">
                     <emphasis>
                         <ulink
                             url="http://framework.zend.com/manual/en/zend.filter.html">
@@ -391,6 +391,11 @@
                     <ulink
                         url="http://www.php.net/manual/en/language.oop5.reflection.php">Reflection</ulink>
                 </entry>
+                <entry>Soft</entry>
+                <entry>
+                    <ulink
+                        url="http://www.php.net/manual/en/ref.zlib.php">zlib</ulink>
+                </entry>
             </row>
             <row>
                 <entry>