migration-110.xml 16 KB

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