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

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

    <para>
        Lors de la migration d'un version précédente vers Zend Framework 1.10 ou plus récent
        vous devriez prendre note de ce qui suit.
    </para>

    <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 eighter 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 validation</title>

            <para>
                Before release 1.10 the <classname>MimeType</classname> validator used a wrong
                naming. For consistency the following constants have been changed:
            </para>

            <table id="migration.110.zend.file.transfer.count.table">
                <title>Changed Validation Messages</title>
                <tgroup cols="4">
                    <thead>
                        <row>
                            <entry>Old</entry>
                            <entry>New</entry>
                            <entry>Value</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>
                When you are translating these messages within your code then use the new constants.
                As benefit you don't need to translate the original string anymore to get a correct
                spelling.
            </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 HTML comments in HTML 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 HTML 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 HTML
            comments, including those containing other HTML 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 adapter</title>

            <para>
                In past the Xliff adapter used the source string as message Id. According to the
                Xliff standard the trans-unit Id should be used. This behaviour was corrected with
                Zend Framework 1.10. Now the trans-unit Id is used as message Id per default.
            </para>

            <para>
                But you can still get the incorrect and old behaviour by setting the
                <property>useId</property> option to <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>Adaptateurs personnels</title>

            <para>
                Lorsqu'une erreur apparait dans un adaptateur crée de toute pièce,
                <methodname>_error()</methodname> doit être appelée. Avant Zend Framework 1.10, il était
                possible d'appeler cette méthode sans aucun paramètre. Le premier template de message d'erreur
                était alors utilisé.
            </para>

            <para>
                Ce comportement est problématique lorsque vous avez des validateurs retournant plusieurs messages.
                Aussi, étendre un validateur peut mener à des comportements inattendus dans une telle situation,
                comme par exemple l'apparition du mauvais message d'erreur.
            </para>

            <programlisting language="php"><![CDATA[
My_Validator extends Zend_Validate_Abstract
{
    public isValid($value)
    {
        ...
        $this->_error(); // Résultat inattendu
        ...
    }
}
]]></programlisting>

            <para>
                Pour éviter ces problèmes <methodname>_error()</methodname> doit desormais
                prendre obligatoirement un paramètre.
            </para>

            <programlisting language="php"><![CDATA[
My_Validator extends Zend_Validate_Abstract
{
    public isValid($value)
    {
        ...
        $this->_error(self::MY_ERROR); // Ok, erreur définie
        ...
    }
}
]]></programlisting>
        </sect3>

        <sect3 id="migration.110.zend.validate.datevalidator">
            <title>Simplification dans le validateur des dates</title>

            <para>
                Avant Zend Framework 1.10, 2 messages identiques étaient envoyés dans le validateur
                des dates. <constant>NOT_YYYY_MM_DD</constant> et
                <constant>FALSEFORMAT</constant>. Depuis Zend Framework 1.10, seul
                <constant>FALSEFORMAT</constant> sera retourné lorsque la date passée ne correspond pas
                au format demandé.
            </para>
        </sect3>

        <sect3 id="migration.110.zend.validate.barcodevalidator">
            <title>Corrections dans Alpha, Alnum et Barcode</title>

            <para>
                Avant Zend Framework 1.10, les messages dans les 2 validateurs barcode, le Alpha
                et le Alnum étaient identiques. Des problèmes pouvaient alors faire surface avec des
                messages personnalisés, des traducteurs ou des instances multiples des validateurs.
            </para>

            <para>
                Depuis Zend Framework 1.10, les valeurs des constantes ont changé pour être uniques.
                Si vous utilisiez les constantes comme le manuel le recommande, aucun changement n'est nécessaire.
                Mais si vous utilisiez les messages d'erreurs, alors il faudra les changer. Voici les changements
                opérés:
            </para>

            <table id="migration.110.zend.validate.barcodevalidator.table">
                <title>Messages de validation disponibles</title>
                <tgroup cols="3">
                    <thead>
                        <row>
                            <entry>Validateur</entry>
                            <entry>Constante</entry>
                            <entry>Valeur</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>