repo_zf1/documentation/manual/ja/ref/performance-view.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<!-- EN-Revision: 15103 -->
<sect1 id="performance.view">
    <title>ビューのレンダリング</title>

    <para>
        Zend FrameworkのMVCレイヤを使うときには、
        <classname>Zend_View</classname>を使うようになる機会があります。
        <classname>Zend_View</classname>は、
        他のビューやテンプレートエンジンに比べて良く機能します。
        ビュースクリプトはPHPで記述されているので、
        PHPにカスタムで加えたコンパイルのオーバーヘッドを招きませんし、
        コンパイルされたPHPが最適されていないかどうか心配する必要もありません。
        しかしながら、<classname>Zend_View</classname>には特有の問題があります:
        エクステンションはオーバーロード経由で実行されます（ビューヘルパ）。
        ビューヘルパの多くは重要な機能を担っていますが、
        性能面でのコストもあります。
    </para>

    <sect2 id="performance.view.pluginloader">
        <title>どのようにしたらビューヘルパの解決を速く出来ますか？</title>

        <para>
            ほとんどの<classname>Zend_View</classname> "メソッド"は、
            実際ヘルパ方式でオーバーロード経由で提供されています。
            これによりZend_Viewに重要な柔軟性が与えられています;
            Zend_Viewを拡張してアプリケーションで利用するであろうすべてのヘルパメソッドを提供する必要の代わりに、
            分離されたクラスにヘルパメソッドを定義して、
            まるでZend_Viewそのもののメソッドであるかのように使い切ることができます。
            このことによりビューオブジェクト自身は比較的身軽に保たれ、
            オブジェクトが必要なときだけ生成されることが保証されます。
        </para>

        <para>
            Internally, <classname>Zend_View</classname> uses the <link
                linkend="zend.loader.pluginloader">PluginLoader</link> to look
            up helper classes. This means that for each helper you call,
            <classname>Zend_View</classname> needs to pass the helper name to the
            PluginLoader, which then needs to determine the class name, load the
            class file if necessary, and then return the class name so it may be
            instantiated. Subsequent uses of the helper are much faster, as
            <classname>Zend_View</classname> keeps an internal registry of loaded helpers,
            but if you use many helpers, the calls add up.
        </para>

        <para>
            それでは質問です: どのようにしたらヘルパの解決を速く出来ますか？
        </para>

        <sect3 id="performance.view.pluginloader.cache">
            <title>ファイルキャッシュを含むPluginLoaderを使う</title>

            <para>
                The simplest, cheapest solution is the same as for <link
                    linkend="performance.classloading.pluginloader">general
                    PluginLoader performance</link>: <link
                    linkend="zend.loader.pluginloader.performance.example">use
                    the PluginLoader include file cache</link>. Anecdotal
                evidence has shown this technique to provide a 25-30%
                performance gain on systems without an opcode cache, and a
                40-65% gain on systems with an opcode cache.
            </para>
        </sect3>

        <sect3 id="performance.view.pluginloader.extend">
            <title>よく使われるヘルパメソッドを提供するようにZend_Viewを拡張する</title>

            <para>
                Another solution for those seeking to tune performance even
                further is to extend <classname>Zend_View</classname> to manually add the
                helper methods they most use in their application. Such helper
                methods may simply manually instantiate the appropriate helper
                class and proxy to it, or stuff the full helper implementation
                into the method.
            </para>

            <programlisting role="php"><![CDATA[
class My_View extends Zend_View
{
    /**
     * @var array Registry of helper classes used
     */
    protected $_localHelperObjects = array();

    /**
     * Proxy to url view helper
     *
     * @param  array $urlOptions Options passed to the assemble method
     *                           of the Route object.
     * @param  mixed $name The name of a Route to use. If null it will
     *                     use the current Route
     * @param  bool $reset Whether or not to reset the route defaults
     *                     with those provided
     * @return string Url for the link href attribute.
     */
    public function url(array $urlOptions = array(), $name = null,
        $reset = false, $encode = true
    ) {
        if (!array_key_exists('url', $this->_localHelperObjects)) {
            $this->_localHelperObjects['url'] = new Zend_View_Helper_Url();
            $this->_localHelperObjects['url']->setView($view);
        }
        $helper = $this->_localHelperObjects['url'];
        return $helper->url($urlOptions, $name, $reset, $encode);
    }

    /**
     * Echo a message
     *
     * Direct implementation.
     *
     * @param  string $string
     * @return string
     */
    public function message($string)
    {
        return "<h1>" . $this->escape($message) . "</h1>\n";
    }
}
]]></programlisting>

            <para>
                Either way, this technique will substantially reduce the
                overhead of the helper system by avoiding calls to the
                PluginLoader entirely, and either benefiting from autoloading or
                bypassing it altogether.
            </para>
        </sect3>
    </sect2>

    <sect2 id="performance.view.partial">
        <title>How can I speed up view partials?</title>

        <para>
            Those who use partials heavily and who profile their applications
            will often immediately notice that the <code>partial()</code> view
            helper incurs a lot of overhead, due to the need to clone the view
            object. Is it possible to speed this up?
        </para>

        <sect3 id="performance.view.partial.render">
            <title>Use partial() only when really necessary</title>

            <para>
                The <code>partial()</code> view helper accepts three arguments:
            </para>

            <itemizedlist>
                <listitem><para>
                    <code>$name</code>: the name of the view script to render
                </para></listitem>

                <listitem><para>
                    <code>$module</code>: the name of the module in which the
                    view script resides; or, if no third argument is provided
                    and this is an array or object, it will be the
                    <code>$model</code> argument.
                </para></listitem>

                <listitem><para>
                    <code>$model</code>: an array or object to pass to the
                    partial representing the clean data to assign to the view.
                </para></listitem>
            </itemizedlist>

            <para>
                The power and use of <code>partial()</code> come from the second
                and third arguments. The <code>$module</code> argument allows
                <code>partial()</code> to temporarily add a script path for the
                given module so that the partial view script will resolve to
                that module; the <code>$model</code> argument allows you to
                explicitly pass variables for use with the partial view.
                If you're not passing either argument, <emphasis>use
                    <code>render()</code> instead</emphasis>!
            </para>

            <para>
                Basically, unless you are actually passing variables to the
                partial and need the clean variable scope, or rendering a view
                script from another MVC module, there is no reason to incur the
                overhead of <code>partial()</code>; instead, use
                <classname>Zend_View</classname>'s built-in <code>render()</code> method
                to render the view script.
            </para>
        </sect3>
    </sect2>

    <sect2 id="performance.view.action">
        <title>どのようにしたらアクションメソッドのビューヘルパの呼び出しを速く出来ますか？</title>

        <para>
            Version 1.5.0 introduced the <code>action()</code> view helper,
            which allows you to dispatch an MVC action and capture its rendered
            content. This provides an important step towards the DRY principle,
            and promotes code reuse. However, as those who profile their
            applications will quickly realize, it, too, is an expensive
            operation. Internally, the <code>action()</code> view helper needs
            to clone new request and response objects, invoke the dispatcher,
            invoke the requested controller and action, etc.
        </para>

        <para>
            How can you speed it up?
        </para>

        <sect3 id="performance.view.action.actionstack">
            <title>可能な場合はActionStackを使う</title>

            <para>
                Introduced at the same time as the <code>action()</code> view
                helper, the <link
                    linkend="zend.controller.actionhelpers.actionstack">ActionStack</link>
                consists of an action helper and a front controller plugin.
                Together, they allow you to push additional actions to invoke
                during the dispatch cycle onto a stack. If you are calling
                <code>action()</code> from your layout view scripts, you may
                want to instead use the ActionStack, and render your views to
                discrete response segments. As an example, you could write a
                <code>dispatchLoopStartup()</code> plugin like the following to
                add a login form box to each page:
            </para>

            <programlisting role="php"><![CDATA[
class LoginPlugin extends Zend_Controller_Plugin_Abstract
{
    protected $_stack;

    public function dispatchLoopStartup(
        Zend_Controller_Request_Abstract $request
    ) {
        $stack = $this->getStack();
        $loginRequest = new Zend_Controller_Request_Simple();
        $loginRequest->setControllerName('user')
                     ->setActionName('index')
                     ->setParam('responseSegment', 'login');
        $stack->pushStack($loginRequest);
    }

    public function getStack()
    {
        if (null === $this->_stack) {
            $front = Zend_Controller_Front::getInstance();
            if (!$front->hasPlugin('Zend_Controller_Plugin_ActionStack')) {
                $stack = new Zend_Controller_Plugin_ActionStack();
                $front->registerPlugin($stack);
            } else {
                $stack = $front->getPlugin('ActionStack')
            }
            $this->_stack = $stack;
        }
        return $this->_stack;
    }
}
]]></programlisting>

            <para>
                The <code>UserController::indexAction()</code> method might then
                use the <code>responseSegment</code> parameter to indicate which
                response segment to render to. In the layout script, you would
                then simply render that response segment:
            </para>

            <programlisting role="php"><![CDATA[
<?php $this->layout()->login ?>
]]></programlisting>

            <para>
                While the ActionStack still requires a dispatch cycle, this is
                still cheaper than the <code>action()</code> view helper as it
                does not need to clone objects and reset internal state.
                Additionally, it ensures that all pre/post dispatch plugins are
                invoked, which may be of particular concern if you are using
                front controller plugins for handling ACLs to particular
                actions.
            </para>
        </sect3>

        <sect3 id="performance.view.action.model">
            <title>Favor helpers that query the model over action()</title>

            <para>
                In most cases, using <code>action()</code> is simply overkill.
                If you have most business logic nested in your models and are
                simply querying the model and passing the results to a view
                script, it will typically be faster and cleaner to simply write
                a view helper that pulls the model, queries it, and does
                something with that information.
            </para>

            <para>
                ひとつの例として、下記のようなコントローラーアクションと
                ビュースクリプトを考えてみましょう:
            </para>

            <programlisting role="php"><![CDATA[
class BugController extends Zend_Controller_Action
{
    public function listAction()
    {
        $model = new Bug();
        $this->view->bugs = $model->fetchActive();
    }
}

// bug/list.phtml:
echo "<ul>\n";
foreach ($this->bugs as $bug) {
    printf("<li><b>%s</b>: %s</li>\n",
        $this->escape($bug->id),
        $this->escape($bug->summary)
    );
}
echo "</ul>\n";
]]></programlisting>

            <para>
                Using <code>action()</code>, you would then invoke it with the
                following:
            </para>

            <programlisting role="php"><![CDATA[
<?php $this->action('list', 'bug') ?>
]]></programlisting>

            <para>
                This could be refactored to a view helper that looks like the
                following:
            </para>

            <programlisting role="php"><![CDATA[
class My_View_Helper_BugList extends Zend_View_Helper_Abstract
{
    public function direct()
    {
        $model = new Bug();
        $html  = "<ul>\n";
        foreach ($model->fetchActive() as $bug) {
            $html .= sprintf(
                "<li><b>%s</b>: %s</li>\n",
                $this->view->escape($bug->id),
                $this->view->escape($bug->summary)
            );
        }
        $html .= "</ul>\n";
        return $html;
    }
}
]]></programlisting>

            <para>
                You would then invoke the helper as follows:
            </para>

            <programlisting role="php"><![CDATA[
<?php $this->bugList() ?>
]]></programlisting>

            <para>
                This has two benefits: it no longer incurs the overhead of the
                <code>action()</code> view helper, and also presents a more
                semantically understandable API.
            </para>
        </sect3>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->