Zend_Validate-Migration.xml 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 17908 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.validate.migration">
  5. <title>Migration von vorhergehenden Versionen</title>
  6. <para>
  7. Die <acronym>API</acronym> von <classname>Zend_Validate</classname> wurde von Zeit zu Zeit
  8. geändert. Wenn man begonnen hat <classname>Zend_Validate</classname> und dessen
  9. Unterkomponenten in früheren Versionen zu verwenden sollte man den folgenden
  10. Richtlinien folgen um eigene Skripte zur neuen <acronym>API</acronym> zu migrieren.
  11. </para>
  12. <sect2 id="zend.validate.migration.fromoneninetooneten">
  13. <title>Migration von 1.9 zu 1.10 oder neuer</title>
  14. <sect3 id="zend.validate.migration.fromoneninetooneten.selfwritten">
  15. <title>Selbst geschriebene Adapter</title>
  16. <para>
  17. Wenn in einer selbst geschriebenen Prüfung ein Fehler gesetzt wird um diesen
  18. zurückzugeben muß die <methodname>_error()</methodname> Methode aufgerufen werden.
  19. Vor Zend Framework 1.10 konnte man diese Methode ohne einen angegebenen Parameter
  20. aufrufen. Es wurde dann das erste gefundene Nachrichtentemplate verwendet.
  21. </para>
  22. <para>
  23. Dieses Verhalten ist problematisch wenn man Prüfungen hat die mehr als eine
  24. Nachricht zurückgeben kann. Auch wenn man eine existierende Prüfung erweitert kann
  25. man unerwartete Ergebnisse erhalten. Das kann zum Problem führen das der Benutzer
  26. nicht die Nachricht erhält die man erwartet.
  27. </para>
  28. <programlisting language="php"><![CDATA[
  29. My_Validator extends Zend_Validate_Abstract
  30. {
  31. public isValid($value)
  32. {
  33. ...
  34. $this->_error(); // Unerwartete Ergebnisse zwischen verschiedenen OS
  35. ...
  36. }
  37. }
  38. ]]></programlisting>
  39. <para>
  40. Um dieses Problem zu verhindern erlaubt es die <methodname>_error()</methodname>
  41. Methode nicht mehr ohne einen angegebenen Parameter aufgerufen zu werden.
  42. </para>
  43. <programlisting language="php"><![CDATA[
  44. My_Validator extends Zend_Validate_Abstract
  45. {
  46. public isValid($value)
  47. {
  48. ...
  49. $this->_error(self::MY_ERROR);
  50. // Definierter Fehler, keine unerwarteten Ergebnisse
  51. ...
  52. }
  53. }
  54. ]]></programlisting>
  55. </sect3>
  56. <sect3 id="zend.validate.migration.fromoneninetooneten.datevalidator">
  57. <title>Vereinfachungen im Date Prüfer</title>
  58. <para>
  59. Vor Zend Framework 1.10 wurden 2 identische Nachrichten im Date Prüfer geworfen.
  60. Es gab <constant>NOT_YYYY_MM_DD</constant> und <constant>FALSEFORMAT</constant>.
  61. Ab Zend Framework 1.10 wird nur mehr die <constant>FALSEFORMAT</constant> Meldung
  62. zurückgegeben wenn das angegebene Datum mit dem gesetzten Format nicht
  63. übereinstimmt.
  64. </para>
  65. </sect3>
  66. <sect3 id="zend.validate.migration.fromoneninetooneten.barcodevalidator">
  67. <title>Fehlerbehebungen im Alpha, Alum und Barcode Prüfer</title>
  68. <para>
  69. Vor dem Zend Framework 1.10 waren Nachrichten in den 2 Barcode Adaptern, dem Alpha
  70. und dem Alnum Prüfer identisch. Das führte zu Problemen bei der Verwendung von
  71. eigenen Meldungen, Übersetzungen oder mehreren Instanzen dieser Prüfer.
  72. </para>
  73. <para>
  74. Mit Zend Framework 1.10 wurden die Werte dieser Konstanten so geändert das Sie
  75. eindeutig sind. Wenn man, so wie es im Handbuhc erklärt wird, die Konstanten
  76. verwendet gibt es keine Änderungen. Aber wenn man den Inhalt der Konstanten im
  77. eigenen Code verwendet dann muß man diese Ändern. Die folgende Tabelle zeigt die
  78. geänderten Werte:
  79. </para>
  80. <table id="zend.validate.migration.fromoneninetooneten.barcodevalidator.table">
  81. <title>Vorhandenen Meldungen der Prüfer</title>
  82. <tgroup cols="3">
  83. <thead>
  84. <row>
  85. <entry>Prüfer</entry>
  86. <entry>Konstante</entry>
  87. <entry>Wert</entry>
  88. </row>
  89. </thead>
  90. <tbody>
  91. <row>
  92. <entry>Alnum</entry>
  93. <entry><constant>STRING_EMPTY</constant></entry>
  94. <entry>alnumStringEmpty</entry>
  95. </row>
  96. <row>
  97. <entry>Alpha</entry>
  98. <entry><constant>STRING_EMPTY</constant></entry>
  99. <entry>alphaStringEmpty</entry>
  100. </row>
  101. <row>
  102. <entry>Barcode_Ean13</entry>
  103. <entry><constant>INVALID</constant></entry>
  104. <entry>ean13Invalid</entry>
  105. </row>
  106. <row>
  107. <entry>Barcode_Ean13</entry>
  108. <entry><constant>INVALID_LENGTH</constant></entry>
  109. <entry>ean13InvalidLength</entry>
  110. </row>
  111. <row>
  112. <entry>Barcode_UpcA</entry>
  113. <entry><constant>INVALID_LENGTH</constant></entry>
  114. <entry>upcaInvalidLength</entry>
  115. </row>
  116. <row>
  117. <entry>Digits</entry>
  118. <entry><constant>STRING_EMPTY</constant></entry>
  119. <entry>digitsStringEmpty</entry>
  120. </row>
  121. </tbody>
  122. </tgroup>
  123. </table>
  124. </sect3>
  125. </sect2>
  126. </sect1>