| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200 |
- <?xml version="1.0" encoding="UTF-8"?>
- <!-- Reviewed: no -->
- <sect1 id="migration.110">
- <title>Zend Framework 1.10</title>
- <para>
- When upgrading from a previous release to Zend Framework 1.10 or higher you
- should note the following migration notes.
- </para>
- <sect2 id="migration.110.zend.file.transfer">
- <title>Zend_File_Transfer</title>
- <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.validate">
- <title>Zend_Validate</title>
- <sect3 id="migration.110.zend.validate.selfwritten">
- <title>Self written validators</title>
- <para>
- When setting returning a error from within a self written validator you have to
- call the <methodname>_error()</methodname> method. Before Zend Framework 1.10 you
- were able to call this method without giving a parameter. It used then the first
- found message template.
- </para>
- <para>
- This behaviour is problematic when you have validators with more than one different
- message to be returned. Also when you extend an existing validator you can get
- unexpected results. This could lead to the problem that your user get not the
- message you expected.
- </para>
- <programlisting language="php"><![CDATA[
- My_Validator extends Zend_Validate_Abstract
- {
- public isValid($value)
- {
- ...
- $this->_error(); // unexpected results between different OS
- ...
- }
- }
- ]]></programlisting>
- <para>
- To prevent this problem the <methodname>_error()</methodname> method is no longer
- allowed to be called without giving a parameter.
- </para>
- <programlisting language="php"><![CDATA[
- My_Validator extends Zend_Validate_Abstract
- {
- public isValid($value)
- {
- ...
- $this->_error(self::MY_ERROR); // defined error, no unexpected results
- ...
- }
- }
- ]]></programlisting>
- </sect3>
- <sect3 id="migration.110.zend.validate.datevalidator">
- <title>Simplification in date validator</title>
- <para>
- Before Zend Framework 1.10 2 identical messages were thrown within the date
- validator. These were <constant>NOT_YYYY_MM_DD</constant> and
- <constant>FALSEFORMAT</constant>. As of Zend Framework 1.10 only the
- <constant>FALSEFORMAT</constant> message will be returned when the given date
- does not match the set format.
- </para>
- </sect3>
- <sect3 id="migration.110.zend.validate.barcodevalidator">
- <title>Fixes in Alpha, Alnum and Barcode validator</title>
- <para>
- Before Zend Framework 1.10 the messages within the 2 barcode adapters, the Alpha
- and the Alnum validator were identical. This introduced problems when using custom
- messages, translations or multiple instances of these validators.
- </para>
- <para>
- As with Zend Framework 1.10 the values of the constants were changed to
- be unique. When you used the constants as proposed in the manual there is
- no change for you. But when you used the content of the constants in your code
- then you will have to change them. The following table shows you the changed values:
- </para>
- <table id="migration.110.zend.validate.barcodevalidator.table">
- <title>Available Validation Messages</title>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Validator</entry>
- <entry>Constant</entry>
- <entry>Value</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>
- <!--
- vim:se ts=4 sw=4 et:
- -->
|