[translation]ja:performance_guide:view

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

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

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- Reviewed: no -->
-<!-- EN-Revision: 15103 -->
+<!-- EN-Revision: 15196 -->
 <sect1 id="performance.view">
     <title>ビューのレンダリング</title>
 
@@ -19,47 +19,51 @@
     </para>
 
     <sect2 id="performance.view.pluginloader">
-        <title>どのようにしたらビューヘルパの解決を速く出来ますか？</title>
+        <title>どのようにしたらビューヘルパの解決を速くできますか？</title>
 
         <para>
-            ほとんどの<classname>Zend_View</classname> "メソッド"は、
+            ほとんどの<classname>Zend_View</classname>の "メソッド" は、
             実際ヘルパ方式でオーバーロード経由で提供されています。
-            これによりZend_Viewに重要な柔軟性が与えられています;
-            Zend_Viewを拡張してアプリケーションで利用するであろうすべてのヘルパメソッドを提供する必要の代わりに、
+            これのおかげで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.
+            内部的には、
+            <classname>Zend_View</classname>はヘルパクラスを探すために
+            <link linkend="zend.loader.pluginloader">プラグインローダー</link>を使います。
+            これはヘルパを呼び出すたびに<classname>Zend_View</classname>がプラグインローダーに
+            ヘルパ名を渡す必要があることを意味しています。
+            プラグインローダーはそれからクラス名を決定し、
+            必要に応じてクラスファイルを読み込み、
+            さらにインスタンス化されるかもしれないクラス名を返します。
+            読み込まれたヘルパを<classname>Zend_View</classname>が内部のレジストリに保持するので、
+            その次にヘルパを使うときにはより速くなります。
+            ただし、多くのヘルパを使うと
+            <!-- TODO -->
+            , the calls add up.
         </para>
 
         <para>
-            それでは質問です: どのようにしたらヘルパの解決を速く出来ますか？
+            それでは質問です: どのようにしたらヘルパの解決を速くできますか？
         </para>
 
         <sect3 id="performance.view.pluginloader.cache">
-            <title>ファイルキャッシュを含むPluginLoaderを使う</title>
+            <title>ファイルキャッシュを含むプラグインローダーを使う</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.
+                最も簡単で安く済む方法は
+                <link linkend="performance.classloading.pluginloader">プラグインのパフォーマンスの向上</link>と同じです:
+                プラグインローダーは
+                <link linkend="zend.loader.pluginloader.performance.example">includeファイルキャッシュ</link>を使います。
+                不確かな証拠によれば、
+                この技術のおかげでopcodeキャッシュがないシステム上では25から30%の、
+                opcodeキャッシュがあるシステム上では40から65%の利得があるそうです。
             </para>
         </sect3>
 
@@ -67,32 +71,28 @@
             <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.
+                さらにもっと性能を調整することを探求する他の方法は、
+                アプリケーションで最も使うヘルパメソッドを手動で<classname>Zend_View</classname>に付加して拡張することです。
+                そのようなヘルパは簡単に適切なヘルパクラスを手動でインスタンス化して、
+                その代わりとなり、
+                あるいはメソッドに完全なヘルパ実装を詰め込みます。
             </para>
 
             <programlisting role="php"><![CDATA[
 class My_View extends Zend_View
 {
     /**
-     * @var array Registry of helper classes used
+     * @var array 使われたヘルパクラスのレジストリ
      */
     protected $_localHelperObjects = array();
 
     /**
-     * Proxy to url view helper
+     * urlビューヘルパの代替
      *
-     * @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.
+     * @param  array $urlOptions ルートオブジェクトを組み立てるメソッドへ渡されるオプション
+     * @param  mixed $name 使用するルート名. nullの場合は現行ルートを使う。
+     * @param  bool $reset それら提供されるデフォルトルートをリセットするか否か
+     * @return string linkのhref属性のためのUrl
      */
     public function url(array $urlOptions = array(), $name = null,
         $reset = false, $encode = true
@@ -106,9 +106,9 @@ class My_View extends Zend_View
     }
 
     /**
-     * Echo a message
+     * メッセージを返す
      *
-     * Direct implementation.
+     * 直接実装
      *
      * @param  string $string
      * @return string
@@ -121,104 +121,99 @@ class My_View extends Zend_View
 ]]></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>
+        <title>どのようにしたらビューを部分的に高速化できますか？</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?
+            部分的に頻繁に利用したり、アプリケーションのプロファイルを実行したりする人は、
+            しばしばすぐにビューオブジェクトのクローンを必要とすることになっている、
+            <code>partial()</code>ビューヘルパがオーバーヘッドの大部分を占めていることに気付くでしょう。
+            これを速度向上させられるでしょうか？
         </para>
 
         <sect3 id="performance.view.partial.render">
-            <title>Use partial() only when really necessary</title>
+            <title>本当に必要な時だけpartial()を使う</title>
 
             <para>
-                The <code>partial()</code> view helper accepts three arguments:
+                <code>partial()</code>ビューヘルパには３つの引数があります:
             </para>
 
             <itemizedlist>
                 <listitem><para>
-                    <code>$name</code>: the name of the view script to render
+                    <code>$name</code>: レンダリングするビュースクリプトの名前
                 </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.
+                    <code>$module</code>: 表示スクリプトが位置するモジュールの名前;
+                    または３番目の引数が渡されない場合、配列またはオブジェクトで、
+                    <code>$model</code>引数
                 </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.
+                    <code>$model</code>: ビューにアサインする純粋なデータを示す部分に渡す配列またはオブジェクト
                 </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>!
+                <code>partial()</code>の威力や使い道は２番目と３番目の引数に依存します。
+                <code>$module</code>引数のおかげで
+                partialビュースクリプトがモジュールを解決するために、
+                与えられたモジュールに<code>partial()</code>が一時的にスクリプトパスを追加できる。;
+                <code>$model</code>引数のおかげでpartialビューを使うために引数を明示的に渡すことができます。
+                もしどちらの引数も渡さないのならば、
+                <emphasis>替わりに</emphasis><code>render()</code>を使ってください！
             </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.
+                基本的に、あなたが実際に変数をその部分に渡して、純粋な変数の範囲を必要とするか、
+                または他のMVCモジュールからビュースクリプトをレンダリングするまで、
+                <code>partial()</code>のオーバーヘッドを受け入れる理由がありません。;
+                その代わり、ビュースクリプトをレンダリングするために、
+                <classname>Zend_View</classname>組込みの<code>render()</code>メソッドを使ってください。
             </para>
         </sect3>
     </sect2>
 
     <sect2 id="performance.view.action">
-        <title>どのようにしたらアクションメソッドのビューヘルパの呼び出しを速く出来ますか？</title>
+        <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.
+            バージョン1.5.0で<code>action()</code>ビューヘルパが導入されました。
+            それによりMVCのアクションをディスパッチして、
+            レンダリングされたコンテンツを入手できるようになります。
+            これはDRY原則に向かう重要なステップで、コードの再利用を促します。
+            しかしながら、アプリケーションをプロファイルする人がすぐ実感するように、
+            これも高くつく操作です。
+            内部的に、<code>action()</code>ビューヘルパでは新しいリクエスト及びレスポンスオブジェクトを複製して、
+            ディスパッチャを呼び出し、求められたコントローラとアクションなどを呼び出す必要があります。
         </para>
 
         <para>
-            How can you speed it up?
+            どうしたら速くできるでしょう？
         </para>
 
         <sect3 id="performance.view.action.actionstack">
-            <title>可能な場合はActionStackを使う</title>
+            <title>可能な場合はアクションスタックを使う</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:
+                <code>action()</code>ビューヘルパと同時期に導入されましたが、
+                <link linkend="zend.controller.actionhelpers.actionstack">アクションスタック</link>
+                はアクションヘルパとフロントコントローラプラグインから成り立ちます。
+                共に、それらのおかげでディスパッチサイクルの間に呼び出すべき、
+                追加のアクションをスタックに押し込むことができます。
+                もしレイアウトビュースクリプトから<code>action()</code>を呼び出しているなら、
+                アクションスタックを使うかわりに、
+                ディスクリートなレスポンスセグメントにビューをレンダリングしたいかもしれません。
+                例えば、各画面にログインフォームの枠を付け加える下記の様な
+                <code>dispatchLoopStartup()</code>プラグインを書けるでしょう。:
             </para>
 
             <programlisting role="php"><![CDATA[
@@ -255,10 +250,9 @@ class LoginPlugin extends Zend_Controller_Plugin_Abstract
 ]]></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:
+                それから<code>UserController::indexAction()</code>メソッドは
+                レンダリングするのがどのレスポンスセグメントかを示す<code>responseSegment</code>パラメータを使うかもしれません。
+                レイアウトスクリプトでそのレスポンスセグメントを単純にレンダリングするでしょう。
             </para>
 
             <programlisting role="php"><![CDATA[
@@ -266,26 +260,26 @@ class LoginPlugin extends Zend_Controller_Plugin_Abstract
 ]]></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.
+                アクションスタックがまだディスパッチサイクルを必要とするのに対して、
+                オブジェクトを複製して内部状態をリセットする必要がないので、
+                <code>action()</code>ビューヘルパよりもっと安くつきます。
+                さらに、それはすべてのプレディスパッチ、
+                またはポストディスパッチのプラグインが呼び出されることを保証します。
+                それは、特別なアクションのためにACLを処理するフロントコントローラプラグインをもし使っているなら、
+                特別に関心があることかもしれません。
             </para>
         </sect3>
 
         <sect3 id="performance.view.action.model">
-            <title>Favor helpers that query the model over action()</title>
+            <title>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.
+                ほとんどの場合、<code>action()</code>を使うのは過剰です。
+                もしモデルの中に業務ロジックをはなはだしく折り重ねていて、
+                モデルに単純に問い合わせて、ビュースクリプトに結果を渡すなら、
+                モデルを引き出してきて問合せを行い、
+                その情報で何かを行うビューヘルパを単純に書くことが、
+                一般的により速くて誤りがないでしょう。
             </para>
 
             <para>
@@ -315,8 +309,8 @@ echo "</ul>\n";
 ]]></programlisting>
 
             <para>
-                Using <code>action()</code>, you would then invoke it with the
-                following:
+                それから<code>action()</code>を使って、
+                下記のようにして呼び出すでしょう:
             </para>
 
             <programlisting role="php"><![CDATA[
@@ -324,14 +318,13 @@ echo "</ul>\n";
 ]]></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()
+    public function bugList()
     {
         $model = new Bug();
         $html  = "<ul>\n";
@@ -349,7 +342,7 @@ class My_View_Helper_BugList extends Zend_View_Helper_Abstract
 ]]></programlisting>
 
             <para>
-                You would then invoke the helper as follows:
+                それからヘルパを下記のように呼び出すでしょう:
             </para>
 
             <programlisting role="php"><![CDATA[
@@ -357,9 +350,9 @@ class My_View_Helper_BugList extends Zend_View_Helper_Abstract
 ]]></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.
+                これには２つの利点があります:
+                それはもはや<code>action()</code>ビューヘルパのオーバーヘッドを受けず、
+                より意味的に理解できるAPIも表現します。
             </para>
         </sect3>
     </sect2>