repo_zf1/documentation/manual/ja/ref/migration-110.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<!-- EN-Revision: 21825 -->
<sect1 id="migration.110">
    <title>Zend Framework 1.10</title>

    <para>
        以前のバージョンから Zend Framework 1.10 またはそれ以降に更新する際は、
        下記の移行上の注意点に注意すべきです。
    </para>

    <sect2 id="migration.110.zend.controller.front">
        <title>Zend_Controller_Front</title>

        <para>
            A wrong behaviour was fixed, when there was no module route and no route
            matched the given request. Previously, the router returned an unmodified
            request object, so the front controller just displayed the default controller
            and action. Since Zend Framework 1.10, the router will correctly as noted
            in the router interface, throw an exception if no route matches. The error
            plugin will then catch that exception and forward to the error controller.
            You can then test for that specific error with the constant
            <constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE</constant>:
        </para>

        <programlisting language="php"><![CDATA[
/**
 * Before 1.10
 */
    public function errorAction()
    {
        $errors = $this->_getParam('error_handler');

        switch ($errors->type) {
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
    // ...

/**
 * With 1.10
 */
    public function errorAction()
    {
        $errors = $this->_getParam('error_handler');

        switch ($errors->type) {
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
    // ...
]]></programlisting>
    </sect2>

    <sect2 id="migration.110.zend.feed.reader">
        <title>Zend_Feed_Reader</title>

        <para>
            With the introduction of Zend Framework 1.10, <classname>Zend_Feed_Reader</classname>'s
            handling of retrieving Authors and Contributors was changed, introducing
            a break in backwards compatibility. This change was an effort to harmonise
            the treatment of such data across the RSS and Atom classes of the component
            and enable the return of Author and Contributor data in more accessible,
            usable and detailed form. It also rectifies an error in that it was assumed
            any author element referred to a name. In RSS this is incorrect as an
            author element is actually only required to provide an email address.
            In addition, the original implementation applied its RSS limits to Atom
            feeds significantly reducing the usefulness of the parser with that format.
        </para>

        <para>
            The change means that methods like <methodname>getAuthors()</methodname>
            and <methodname>getContributors</methodname> no longer return a simple array
            of strings parsed from the relevant RSS and Atom elements. Instead, the return
            value is an <classname>ArrayObject</classname> subclass called
            <classname>Zend_Feed_Reader_Collection_Author</classname> which simulates
            an iterable multidimensional array of Authors. Each member of this object
            will be a simple array with three potential keys (as the source data permits).
            These include: name, email and uri.
        </para>

        <para>
            The original behaviour of such methods would have returned a simple
            array of strings, each string attempting to present a single name, but
            in reality this was unreliable since there is no rule governing the format
            of RSS Author strings.
        </para>

        <para>
            The simplest method of simulating the original behaviour of these
            methods is to use the <classname>Zend_Feed_Reader_Collection_Author</classname>'s
            <methodname>getValues()</methodname> which also returns a simple array of strings
            representing the "most relevant data", for authors presumed to be their name.
            Each value in the resulting array is derived from the "name" value
            attached to each Author (if present). In most cases this simple change is
            easy to apply as demonstrated below.
        </para>

        <programlisting language="php"><![CDATA[
/**
 * Before 1.10
 */
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors();

/**
 * With 1.10
 */
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors()->getValues();
]]></programlisting>
    </sect2>

    <sect2 id="migration.110.zend.file.transfer">
        <title>Zend_File_Transfer</title>

        <sect3 id="migration.110.zend.file.transfer.files">
            <title>Security change</title>

            <para>
                For security reasons <classname>Zend_File_Transfer</classname> does no longer store
                the original mimetype and filesize which is given from the requesting client into
                its internal storage. Instead the real values will be detected at initiation.
            </para>

            <para>
                Additionally the original values within <varname>$_FILES</varname> will be
                overridden within the real values at initiation. This makes also
                <varname>$_FILES</varname> secure.
            </para>

            <para>
                When you are in need of the original values you can either store them before
                initiating <classname>Zend_File_Transfer</classname> or use the
                <property>disableInfos</property> option at initiation. Note that this option is
                useless when its given after initiation.
            </para>
        </sect3>

        <sect3 id="migration.110.zend.file.transfer.count">
            <title>Count 検証</title>

            <para>
                リリース 1.10 より前は <classname>MimeType</classname> バリデータが誤った命名を使っていました。
                一貫性のために、下記の定数が変更されました。
            </para>

            <table id="migration.110.zend.file.transfer.count.table">
                <title>変更された検証メッセージ</title>

                <tgroup cols="4">
                    <thead>
                        <row>
                            <entry>旧</entry>
                            <entry>新</entry>
                            <entry>値</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry><constant>TOO_MUCH</constant></entry>
                            <entry><constant>TOO_MANY</constant></entry>

                            <entry>
                                Too many files, maximum '%max%' are allowed but '%count%' are given
                            </entry>
                        </row>

                        <row>
                            <entry><constant>TOO_LESS</constant></entry>
                            <entry><constant>TOO_FEW</constant></entry>

                            <entry>
                                Too few files, minimum '%min%' are expected but '%count%' are given
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>

            <para>
                コード内でこれらのメッセージを翻訳している場合、新しい定数を使います。
                利点として、正しいつづりを得るために、本来の文字列を翻訳する必要はもうありません。
            </para>
        </sect3>
    </sect2>

    <sect2 id="migration.110.zend.filter.html-entities">
        <title>Zend_Filter_HtmlEntities</title>

        <para>
            In order to default to a more secure character encoding,
            <classname>Zend_Filter_HtmlEntities</classname> now defaults to <acronym>UTF-8</acronym>
            instead of <acronym>ISO-8859-1</acronym>.
        </para>

        <para>
            Additionally, because the actual mechanism is dealing with character encodings and not
            character sets, two new methods have been added, <methodname>setEncoding()</methodname>
            and <methodname>getEncoding()</methodname>. The previous methods
            <methodname>setCharSet()</methodname> and <methodname>setCharSet()</methodname> are now
            deprecated and proxy to the new methods. Finally, instead of using the protected members
            directly within the <methodname>filter()</methodname> method, these members are
            retrieved by their explicit accessors. If you were extending the filter in the past,
            please check your code and unit tests to ensure everything still continues to work.
        </para>
    </sect2>

    <sect2 id="migration.110.zend.filter.strip-tags">
        <title>Zend_Filter_StripTags</title>

        <para>
            <classname>Zend_Filter_StripTags</classname> contains a flag,
            <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
            optionally whitelist <acronym>HTML</acronym> comments in <acronym>HTML</acronym> text
            filtered by the class. However, this opens code enabling the flag to
            <acronym>XSS</acronym> attacks, particularly in Internet Explorer (which allows
            specifying conditional functionality via <acronym>HTML</acronym> comments). Starting
            in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
            <varname>commentsAllowed</varname> flag no longer has any meaning, and all
            <acronym>HTML</acronym> comments, including those containing other
            <acronym>HTML</acronym> tags or nested commments, will be stripped from the final output
            of the filter.
        </para>
    </sect2>

    <sect2 id="migration.110.zend.translate">
        <title>Zend_Translate</title>

        <sect3 id="migration.110.zend.translate.xliff">
            <title>Xliff アダプタ</title>

            <para>
                過去には Xliff アダプタはソースの文字列をメッセージ Id として使いました。
                Xliff 標準に沿って、翻訳単位 Id が使われるべきです。
                この振る舞いは Zend Framework 1.10 で修正されました。
                今では既定では翻訳単位 Id はメッセージId として使われます。
            </para>

            <para>
                しかし、 <property>useId</property> オプションを <constant>FALSE</constant> に設定することにより、
                正しくなくて古い振る舞いをまだ得られます。
                
            </para>

            <programlisting language="php"><![CDATA[
$trans = new Zend_Translate(
    'xliff', '/path/to/source', $locale, array('useId' => false)
);
]]></programlisting>
        </sect3>
    </sect2>

    <sect2 id="migration.110.zend.validate">
        <title>Zend_Validate</title>

        <sect3 id="migration.110.zend.validate.selfwritten">
            <title>書かれたバリデータ自身</title>

            <para>
                かかれたバリデータ自身の内部からエラーを返すよう設定するときは、
                <methodname>_error()</methodname>メソッドを呼ばなくてはいけません。
                Zend Framework 1.10 以前では、パラメータを与えなくてもこのメソッドを呼び出せました。
                そこで、最初に見つかったメッセージテンプレートを使いました。
            </para>

            <para>
                この振る舞いには、一つ以上の異なるメッセージを返すバリデータを使うときに問題があります。
                また、既存のバリデータを拡張すると、予期しない結果を得ることもあります。
                このせいで、あなたが期待した通りではないメッセージにユーザーが遭遇することにもなりました。
            </para>

            <programlisting language="php"><![CDATA[
My_Validator extends Zend_Validate_Abstract
{
    public isValid($value)
    {
        ...
        $this->_error(); // 異なるOS間での予期されない結果
        ...
    }
}
]]></programlisting>

            <para>
                この問題を防ぐために、<methodname>_error()</methodname>メソッドにパラメータを与えないで呼び出すことは、
                もはやできなくなります。
            </para>

            <programlisting language="php"><![CDATA[
My_Validator extends Zend_Validate_Abstract
{
    public isValid($value)
    {
        ...
        $this->_error(self::MY_ERROR); // 定義されたエラー、予期されない結果ではありません
        ...
    }
}
]]></programlisting>
        </sect3>

        <sect3 id="migration.110.zend.validate.datevalidator">
            <title>日付バリデータの簡略化</title>

            <para>
                Zend Framework 1.10 以前では、同一の２つのメッセージが、
                日付バリデータ内でスローされていました。
                これらは、<constant>NOT_YYYY_MM_DD</constant>と<constant>FALSEFORMAT</constant>でした。
                Zend Framework 1.10 現在では、
                与えられた日付が設定されたフォーマットに一致しない場合、
                <constant>FALSEFORMAT</constant>メッセージだけが返されます。
            </para>
        </sect3>

        <sect3 id="migration.110.zend.validate.barcodevalidator">
            <title>Alpha、Alnum及びBarcodeバリデータの修正</title>

            <para>
                Zend Framework 1.10 以前では、バーコード・アダプタ２種類と、
                Alpha 及び Alnum バリデータ内のメッセージが同一でした。
                このため、カスタムのメッセージ、翻訳、
                またはこれらのバリデータの複数のインスタンスを使うときに問題がありました。
            </para>

            <para>
                Zend Framework 1.10 では、定数値は、一意であるように変更されました。
                マニュアルで提案されたように定数を使ったときには、変更がありません。
                しかし、コードで定数の内容を使ったときには、
                それらを変更しなければなりません。
                下記の表では変更された値を示します。
            </para>

            <table id="migration.110.zend.validate.barcodevalidator.table">
                <title>利用可能なバリデータのメッセージ</title>

                <tgroup cols="3">
                    <thead>
                        <row>
                            <entry>バリデータ</entry>
                            <entry>定数</entry>
                            <entry>値</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry><classname>Alnum</classname></entry>
                            <entry><constant>STRING_EMPTY</constant></entry>
                            <entry>alnumStringEmpty</entry>
                        </row>

                        <row>
                            <entry><classname>Alpha</classname></entry>
                            <entry><constant>STRING_EMPTY</constant></entry>
                            <entry>alphaStringEmpty</entry>
                        </row>

                        <row>
                            <entry><classname>Barcode_Ean13</classname></entry>
                            <entry><constant>INVALID</constant></entry>
                            <entry>ean13Invalid</entry>
                        </row>

                        <row>
                            <entry><classname>Barcode_Ean13</classname></entry>
                            <entry><constant>INVALID_LENGTH</constant></entry>
                            <entry>ean13InvalidLength</entry>
                        </row>

                        <row>
                            <entry><classname>Barcode_UpcA</classname></entry>
                            <entry><constant>INVALID</constant></entry>
                            <entry>upcaInvalid</entry>
                        </row>

                        <row>
                            <entry><classname>Barcode_UpcA</classname></entry>
                            <entry><constant>INVALID_LENGTH</constant></entry>
                            <entry>upcaInvalidLength</entry>
                        </row>

                        <row>
                            <entry><classname>Digits</classname></entry>
                            <entry><constant>STRING_EMPTY</constant></entry>
                            <entry>digitsStringEmpty</entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>

        </sect3>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->