migration-110.xml 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="migration.110">
  4. <title>Zend Framework 1.10</title>
  5. <para>
  6. When upgrading from a previous release to Zend Framework 1.10 or higher you
  7. should note the following migration notes.
  8. </para>
  9. <sect2 id="migration.110.zend.file.transfer">
  10. <title>Zend_File_Transfer</title>
  11. <sect3 id="migration.110.zend.file.transfer.count">
  12. <title>Count validation</title>
  13. <para>
  14. Before release 1.10 the <classname>MimeType</classname> validator used a wrong
  15. naming. For consistency the following constants have been changed:
  16. </para>
  17. <table id="migration.110.zend.file.transfer.count.table">
  18. <title>Changed Validation Messages</title>
  19. <tgroup cols="4">
  20. <thead>
  21. <row>
  22. <entry>Old</entry>
  23. <entry>New</entry>
  24. <entry>Value</entry>
  25. </row>
  26. </thead>
  27. <tbody>
  28. <row>
  29. <entry><constant>TOO_MUCH</constant></entry>
  30. <entry><constant>TOO_MANY</constant></entry>
  31. <entry>
  32. Too many files, maximum '%max%' are allowed but '%count%' are given
  33. </entry>
  34. </row>
  35. <row>
  36. <entry><constant>TOO_LESS</constant></entry>
  37. <entry><constant>TOO_FEW</constant></entry>
  38. <entry>
  39. Too few files, minimum '%min%' are expected but '%count%' are given
  40. </entry>
  41. </row>
  42. </tbody>
  43. </tgroup>
  44. </table>
  45. <para>
  46. When you are translating these messages within your code then use the new constants.
  47. As benefit you don't need to translate the original string anymore to get a correct
  48. spelling.
  49. </para>
  50. </sect3>
  51. </sect2>
  52. <sect2 id="migration.110.zend.translate">
  53. <title>Zend_Translate</title>
  54. <sect3 id="migration.110.zend.translate.xliff">
  55. <title>Xliff adapter</title>
  56. <para>
  57. In past the Xliff adapter used the source string as message Id. According to the
  58. Xliff standard the trans-unit Id should be used. This behaviour was corrected with
  59. Zend Framework 1.10. Now the trans-unit Id is used as message Id per default.
  60. </para>
  61. <para>
  62. But you can still get the incorrect and old behaviour by setting the
  63. <property>useId</property> option to <constant>FALSE</constant>.
  64. </para>
  65. <programlisting language="php"><![CDATA[
  66. $trans = new Zend_Translate('xliff', '/path/to/source', $locale, array('useId' => false));
  67. ]]></programlisting>
  68. </sect3>
  69. </sect2>
  70. <sect2 id="migration.110.zend.validate">
  71. <title>Zend_Validate</title>
  72. <sect3 id="migration.110.zend.validate.selfwritten">
  73. <title>Self written validators</title>
  74. <para>
  75. When setting returning a error from within a self written validator you have to
  76. call the <methodname>_error()</methodname> method. Before Zend Framework 1.10 you
  77. were able to call this method without giving a parameter. It used then the first
  78. found message template.
  79. </para>
  80. <para>
  81. This behaviour is problematic when you have validators with more than one different
  82. message to be returned. Also when you extend an existing validator you can get
  83. unexpected results. This could lead to the problem that your user get not the
  84. message you expected.
  85. </para>
  86. <programlisting language="php"><![CDATA[
  87. My_Validator extends Zend_Validate_Abstract
  88. {
  89. public isValid($value)
  90. {
  91. ...
  92. $this->_error(); // unexpected results between different OS
  93. ...
  94. }
  95. }
  96. ]]></programlisting>
  97. <para>
  98. To prevent this problem the <methodname>_error()</methodname> method is no longer
  99. allowed to be called without giving a parameter.
  100. </para>
  101. <programlisting language="php"><![CDATA[
  102. My_Validator extends Zend_Validate_Abstract
  103. {
  104. public isValid($value)
  105. {
  106. ...
  107. $this->_error(self::MY_ERROR); // defined error, no unexpected results
  108. ...
  109. }
  110. }
  111. ]]></programlisting>
  112. </sect3>
  113. <sect3 id="migration.110.zend.validate.datevalidator">
  114. <title>Simplification in date validator</title>
  115. <para>
  116. Before Zend Framework 1.10 2 identical messages were thrown within the date
  117. validator. These were <constant>NOT_YYYY_MM_DD</constant> and
  118. <constant>FALSEFORMAT</constant>. As of Zend Framework 1.10 only the
  119. <constant>FALSEFORMAT</constant> message will be returned when the given date
  120. does not match the set format.
  121. </para>
  122. </sect3>
  123. <sect3 id="migration.110.zend.validate.barcodevalidator">
  124. <title>Fixes in Alpha, Alnum and Barcode validator</title>
  125. <para>
  126. Before Zend Framework 1.10 the messages within the 2 barcode adapters, the Alpha
  127. and the Alnum validator were identical. This introduced problems when using custom
  128. messages, translations or multiple instances of these validators.
  129. </para>
  130. <para>
  131. As with Zend Framework 1.10 the values of the constants were changed to
  132. be unique. When you used the constants as proposed in the manual there is
  133. no change for you. But when you used the content of the constants in your code
  134. then you will have to change them. The following table shows you the changed values:
  135. </para>
  136. <table id="migration.110.zend.validate.barcodevalidator.table">
  137. <title>Available Validation Messages</title>
  138. <tgroup cols="3">
  139. <thead>
  140. <row>
  141. <entry>Validator</entry>
  142. <entry>Constant</entry>
  143. <entry>Value</entry>
  144. </row>
  145. </thead>
  146. <tbody>
  147. <row>
  148. <entry><classname>Alnum</classname></entry>
  149. <entry><constant>STRING_EMPTY</constant></entry>
  150. <entry>alnumStringEmpty</entry>
  151. </row>
  152. <row>
  153. <entry><classname>Alpha</classname></entry>
  154. <entry><constant>STRING_EMPTY</constant></entry>
  155. <entry>alphaStringEmpty</entry>
  156. </row>
  157. <row>
  158. <entry><classname>Barcode_Ean13</classname></entry>
  159. <entry><constant>INVALID</constant></entry>
  160. <entry>ean13Invalid</entry>
  161. </row>
  162. <row>
  163. <entry><classname>Barcode_Ean13</classname></entry>
  164. <entry><constant>INVALID_LENGTH</constant></entry>
  165. <entry>ean13InvalidLength</entry>
  166. </row>
  167. <row>
  168. <entry><classname>Barcode_UpcA</classname></entry>
  169. <entry><constant>INVALID</constant></entry>
  170. <entry>upcaInvalid</entry>
  171. </row>
  172. <row>
  173. <entry><classname>Barcode_UpcA</classname></entry>
  174. <entry><constant>INVALID_LENGTH</constant></entry>
  175. <entry>upcaInvalidLength</entry>
  176. </row>
  177. <row>
  178. <entry><classname>Digits</classname></entry>
  179. <entry><constant>STRING_EMPTY</constant></entry>
  180. <entry>digitsStringEmpty</entry>
  181. </row>
  182. </tbody>
  183. </tgroup>
  184. </table>
  185. </sect3>
  186. </sect2>
  187. </sect1>
  188. <!--
  189. vim:se ts=4 sw=4 et:
  190. -->