[ZF-10089] Zend_Log
[zend.git] / documentation / manual / fr / ref / migration-110.xml
blob3759ec1a766c299c2bdc012902525ee3065e09da
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!-- EN-Revision: 21825 -->
3 <!-- Reviewed: no -->
4 <sect1 id="migration.110">
5     <title>Zend Framework 1.10</title>
7     <para>
8         Lors de la migration d'un version précédente vers Zend Framework 1.10 ou plus récent
9         vous devriez prendre note de ce qui suit.
10     </para>
12     <sect2 id="migration.110.zend.controller.front">
13         <title>Zend_Controller_Front</title>
15         <para>
16             A wrong behaviour was fixed, when there was no module route and no route
17             matched the given request. Previously, the router returned an unmodified
18             request object, so the front controller just displayed the default controller
19             and action. Since Zend Framework 1.10, the router will correctly as noted
20             in the router interface, throw an exception if no route matches. The error
21             plugin will then catch that exception and forward to the error controller.
22             You can then test for that specific error with the constant
23             <constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE</constant>:
24         </para>
26         <programlisting language="php"><![CDATA[
27 /**
28  * Before 1.10
29  */
30     public function errorAction()
31     {
32         $errors = $this->_getParam('error_handler');
34         switch ($errors->type) {
35             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
36             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
37     // ...
39 /**
40  * With 1.10
41  */
42     public function errorAction()
43     {
44         $errors = $this->_getParam('error_handler');
46         switch ($errors->type) {
47             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE:
48             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
49             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
50     // ...
51 ]]></programlisting>
52     </sect2>
54     <sect2 id="migration.110.zend.feed.reader">
55         <title>Zend_Feed_Reader</title>
57         <para>
58             With the introduction of Zend Framework 1.10, <classname>Zend_Feed_Reader</classname>'s
59             handling of retrieving Authors and Contributors was changed, introducing
60             a break in backwards compatibility. This change was an effort to harmonise
61             the treatment of such data across the RSS and Atom classes of the component
62             and enable the return of Author and Contributor data in more accessible,
63             usable and detailed form. It also rectifies an error in that it was assumed
64             any author element referred to a name. In RSS this is incorrect as an
65             author element is actually only required to provide an email address.
66             In addition, the original implementation applied its RSS limits to Atom
67             feeds significantly reducing the usefulness of the parser with that format.
68         </para>
70         <para>
71             The change means that methods like <methodname>getAuthors()</methodname>
72             and <methodname>getContributors</methodname> no longer return a simple array
73             of strings parsed from the relevant RSS and Atom elements. Instead, the return
74             value is an <classname>ArrayObject</classname> subclass called
75             <classname>Zend_Feed_Reader_Collection_Author</classname> which simulates
76             an iterable multidimensional array of Authors. Each member of this object
77             will be a simple array with three potential keys (as the source data permits).
78             These include: name, email and uri.
79         </para>
81         <para>
82             The original behaviour of such methods would have returned a simple
83             array of strings, each string attempting to present a single name, but
84             in reality this was unreliable since there is no rule governing the format
85             of RSS Author strings.
86         </para>
88         <para>
89             The simplest method of simulating the original behaviour of these
90             methods is to use the <classname>Zend_Feed_Reader_Collection_Author</classname>'s
91             <methodname>getValues()</methodname> which also returns a simple array of strings
92             representing the "most relevant data", for authors presumed to be their name.
93             Each value in the resulting array is derived from the "name" value
94             attached to each Author (if present). In most cases this simple change is
95             easy to apply as demonstrated below.
96         </para>
98         <programlisting language="php"><![CDATA[
99 /**
100  * Before 1.10
101  */
103 $feed = Zend_Feed_Reader::import('http://example.com/feed');
104 $authors = $feed->getAuthors();
107  * With 1.10
108  */
109 $feed = Zend_Feed_Reader::import('http://example.com/feed');
110 $authors = $feed->getAuthors()->getValues();
111 ]]></programlisting>
112     </sect2>
114     <sect2 id="migration.110.zend.file.transfer">
115         <title>Zend_File_Transfer</title>
117         <sect3 id="migration.110.zend.file.transfer.files">
118             <title>Security change</title>
120             <para>
121                 For security reasons <classname>Zend_File_Transfer</classname> does no longer store
122                 the original mimetype and filesize which is given from the requesting client into
123                 its internal storage. Instead the real values will be detected at initiation.
124             </para>
126             <para>
127                 Additionally the original values within <varname>$_FILES</varname> will be
128                 overridden within the real values at initiation. This makes also
129                 <varname>$_FILES</varname> secure.
130             </para>
132             <para>
133                 When you are in need of the original values you can either store them before
134                 initiating <classname>Zend_File_Transfer</classname> or use the
135                 <property>disableInfos</property> option at initiation. Note that this option is
136                 useless when its given after initiation.
137             </para>
138         </sect3>
140         <sect3 id="migration.110.zend.file.transfer.count">
141             <title>Count validation</title>
143             <para>
144                 Before release 1.10 the <classname>MimeType</classname> validator used a wrong
145                 naming. For consistency the following constants have been changed:
146             </para>
148             <table id="migration.110.zend.file.transfer.count.table">
149                 <title>Changed Validation Messages</title>
150                 <tgroup cols="4">
151                     <thead>
152                         <row>
153                             <entry>Old</entry>
154                             <entry>New</entry>
155                             <entry>Value</entry>
156                         </row>
157                     </thead>
159                     <tbody>
160                         <row>
161                             <entry><constant>TOO_MUCH</constant></entry>
162                             <entry><constant>TOO_MANY</constant></entry>
163                             <entry>
164                                 Too many files, maximum '%max%' are allowed but '%count%' are given
165                             </entry>
166                         </row>
168                         <row>
169                             <entry><constant>TOO_LESS</constant></entry>
170                             <entry><constant>TOO_FEW</constant></entry>
171                             <entry>
172                                 Too few files, minimum '%min%' are expected but '%count%' are given
173                             </entry>
174                         </row>
175                     </tbody>
176                 </tgroup>
177             </table>
179             <para>
180                 When you are translating these messages within your code then use the new constants.
181                 As benefit you don't need to translate the original string anymore to get a correct
182                 spelling.
183             </para>
184         </sect3>
185     </sect2>
187     <sect2 id="migration.110.zend.filter.html-entities">
188         <title>Zend_Filter_HtmlEntities</title>
190         <para>
191             In order to default to a more secure character encoding,
192             <classname>Zend_Filter_HtmlEntities</classname> now defaults to <acronym>UTF-8</acronym>
193             instead of <acronym>ISO-8859-1</acronym>.
194         </para>
196         <para>
197             Additionally, because the actual mechanism is dealing with character encodings and not
198             character sets, two new methods have been added, <methodname>setEncoding()</methodname>
199             and <methodname>getEncoding()</methodname>. The previous methods
200             <methodname>setCharSet()</methodname> and <methodname>setCharSet()</methodname> are now
201             deprecated and proxy to the new methods. Finally, instead of using the protected members
202             directly within the <methodname>filter()</methodname> method, these members are
203             retrieved by their explicit accessors. If you were extending the filter in the past,
204             please check your code and unit tests to ensure everything still continues to work.
205         </para>
206     </sect2>
208     <sect2 id="migration.110.zend.filter.strip-tags">
209         <title>Zend_Filter_StripTags</title>
211         <para>
212             <classname>Zend_Filter_StripTags</classname> contains a flag,
213             <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
214             optionally whitelist <acronym>HTML</acronym> comments in <acronym>HTML</acronym> text
215             filtered by the class. However, this opens code enabling the flag to
216             <acronym>XSS</acronym> attacks, particularly in Internet Explorer (which allows
217             specifying conditional functionality via <acronym>HTML</acronym> comments). Starting
218             in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
219             <varname>commentsAllowed</varname> flag no longer has any meaning, and all
220             <acronym>HTML</acronym> comments, including those containing other
221             <acronym>HTML</acronym> tags or nested commments, will be stripped from the final output
222             of the filter.
223         </para>
224     </sect2>
226     <sect2 id="migration.110.zend.translate">
227         <title>Zend_Translate</title>
229         <sect3 id="migration.110.zend.translate.xliff">
230             <title>Xliff adapter</title>
232             <para>
233                 In past the Xliff adapter used the source string as message Id. According to the
234                 Xliff standard the trans-unit Id should be used. This behaviour was corrected with
235                 Zend Framework 1.10. Now the trans-unit Id is used as message Id per default.
236             </para>
238             <para>
239                 But you can still get the incorrect and old behaviour by setting the
240                 <property>useId</property> option to <constant>FALSE</constant>.
241             </para>
243             <programlisting language="php"><![CDATA[
244 $trans = new Zend_Translate(
245     'xliff', '/path/to/source', $locale, array('useId' => false)
247 ]]></programlisting>
248         </sect3>
249     </sect2>
251     <sect2 id="migration.110.zend.validate">
252         <title>Zend_Validate</title>
254         <sect3 id="migration.110.zend.validate.selfwritten">
255             <title>Adaptateurs personnels</title>
257             <para>
258                 Lorsqu'une erreur apparait dans un adaptateur crée de toute pièce,
259                 <methodname>_error()</methodname> doit être appelée. Avant Zend Framework 1.10, il était
260                 possible d'appeler cette méthode sans aucun paramètre. Le premier template de message d'erreur
261                 était alors utilisé.
262             </para>
264             <para>
265                 Ce comportement est problématique lorsque vous avez des validateurs retournant plusieurs messages.
266                 Aussi, étendre un validateur peut mener à des comportements inattendus dans une telle situation,
267                 comme par exemple l'apparition du mauvais message d'erreur.
268             </para>
270             <programlisting language="php"><![CDATA[
271 My_Validator extends Zend_Validate_Abstract
273     public isValid($value)
274     {
275         ...
276         $this->_error(); // Résultat inattendu
277         ...
278     }
280 ]]></programlisting>
282             <para>
283                 Pour éviter ces problèmes <methodname>_error()</methodname> doit desormais
284                 prendre obligatoirement un paramètre.
285             </para>
287             <programlisting language="php"><![CDATA[
288 My_Validator extends Zend_Validate_Abstract
290     public isValid($value)
291     {
292         ...
293         $this->_error(self::MY_ERROR); // Ok, erreur définie
294         ...
295     }
297 ]]></programlisting>
298         </sect3>
300         <sect3 id="migration.110.zend.validate.datevalidator">
301             <title>Simplification dans le validateur des dates</title>
303             <para>
304                 Avant Zend Framework 1.10, 2 messages identiques étaient envoyés dans le validateur
305                 des dates. <constant>NOT_YYYY_MM_DD</constant> et
306                 <constant>FALSEFORMAT</constant>. Depuis Zend Framework 1.10, seul
307                 <constant>FALSEFORMAT</constant> sera retourné lorsque la date passée ne correspond pas
308                 au format demandé.
309             </para>
310         </sect3>
312         <sect3 id="migration.110.zend.validate.barcodevalidator">
313             <title>Corrections dans Alpha, Alnum et Barcode</title>
315             <para>
316                 Avant Zend Framework 1.10, les messages dans les 2 validateurs barcode, le Alpha
317                 et le Alnum étaient identiques. Des problèmes pouvaient alors faire surface avec des
318                 messages personnalisés, des traducteurs ou des instances multiples des validateurs.
319             </para>
321             <para>
322                 Depuis Zend Framework 1.10, les valeurs des constantes ont changé pour être uniques.
323                 Si vous utilisiez les constantes comme le manuel le recommande, aucun changement n'est nécessaire.
324                 Mais si vous utilisiez les messages d'erreurs, alors il faudra les changer. Voici les changements
325                 opérés:
326             </para>
328             <table id="migration.110.zend.validate.barcodevalidator.table">
329                 <title>Messages de validation disponibles</title>
330                 <tgroup cols="3">
331                     <thead>
332                         <row>
333                             <entry>Validateur</entry>
334                             <entry>Constante</entry>
335                             <entry>Valeur</entry>
336                         </row>
337                     </thead>
339                     <tbody>
340                         <row>
341                             <entry><classname>Alnum</classname></entry>
342                             <entry><constant>STRING_EMPTY</constant></entry>
343                             <entry>alnumStringEmpty</entry>
344                         </row>
346                         <row>
347                             <entry><classname>Alpha</classname></entry>
348                             <entry><constant>STRING_EMPTY</constant></entry>
349                             <entry>alphaStringEmpty</entry>
350                         </row>
352                         <row>
353                             <entry><classname>Barcode_Ean13</classname></entry>
354                             <entry><constant>INVALID</constant></entry>
355                             <entry>ean13Invalid</entry>
356                         </row>
358                         <row>
359                             <entry><classname>Barcode_Ean13</classname></entry>
360                             <entry><constant>INVALID_LENGTH</constant></entry>
361                             <entry>ean13InvalidLength</entry>
362                         </row>
364                         <row>
365                             <entry><classname>Barcode_UpcA</classname></entry>
366                             <entry><constant>INVALID</constant></entry>
367                             <entry>upcaInvalid</entry>
368                         </row>
370                         <row>
371                             <entry><classname>Barcode_UpcA</classname></entry>
372                             <entry><constant>INVALID_LENGTH</constant></entry>
373                             <entry>upcaInvalidLength</entry>
374                         </row>
376                         <row>
377                             <entry><classname>Digits</classname></entry>
378                             <entry><constant>STRING_EMPTY</constant></entry>
379                             <entry>digitsStringEmpty</entry>
380                         </row>
381                     </tbody>
382                 </tgroup>
383             </table>
384         </sect3>
385     </sect2>
386 </sect1>