1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
|
<?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.controller.front">
<title>Zend_Controller_Front</title>
<para>
A wrong behaviour was fixed, when there was no module route and no route
matched the given request. Previously, the router returned an unmodified
request object, so the front controller just displayed the default controller
and action. Since Zend Framework 1.10, the router will correctly as noted
in the router interface, throw an exception if no route matches. The error
plugin will then catch that exception and forward to the error controller.
You can then test for that specific error with the constant
<constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE</constant>:
</para>
<programlisting language="php"><![CDATA[
/**
* Before 1.10
*/
public function errorAction()
{
$errors = $this->_getParam('error_handler');
switch ($errors->type) {
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
// ...
/**
* With 1.10
*/
public function errorAction()
{
$errors = $this->_getParam('error_handler');
switch ($errors->type) {
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE:
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
// ...
]]></programlisting>
</sect2>
<sect2 id="migration.110.zend.feed.reader">
<title>Zend_Feed_Reader</title>
<para>
With the introduction of Zend Framework 1.10, <classname>Zend_Feed_Reader</classname>'s
handling of retrieving Authors and Contributors was changed, introducing
a break in backwards compatibility. This change was an effort to harmonise
the treatment of such data across the RSS and Atom classes of the component
and enable the return of Author and Contributor data in more accessible,
usable and detailed form. It also rectifies an error in that it was assumed
any author element referred to a name. In RSS this is incorrect as an
author element is actually only required to provide an email address.
In addition, the original implementation applied its RSS limits to Atom
feeds significantly reducing the usefulness of the parser with that format.
</para>
<para>
The change means that methods like <methodname>getAuthors()</methodname>
and <methodname>getContributors</methodname> no longer return a simple array
of strings parsed from the relevant RSS and Atom elements. Instead, the return
value is an <classname>ArrayObject</classname> subclass called
<classname>Zend_Feed_Reader_Collection_Author</classname> which simulates
an iterable multidimensional array of Authors. Each member of this object
will be a simple array with three potential keys (as the source data permits).
These include: name, email and uri.
</para>
<para>
The original behaviour of such methods would have returned a simple
array of strings, each string attempting to present a single name, but
in reality this was unreliable since there is no rule governing the format
of RSS Author strings.
</para>
<para>
The simplest method of simulating the original behaviour of these
methods is to use the <classname>Zend_Feed_Reader_Collection_Author</classname>'s
<methodname>getValues()</methodname> which also returns a simple array of strings
representing the "most relevant data", for authors presumed to be their name.
Each value in the resulting array is derived from the "name" value
attached to each Author (if present). In most cases this simple change is
easy to apply as demonstrated below.
</para>
<programlisting language="php"><![CDATA[
/**
* Before 1.10
*/
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors();
/**
* With 1.10
*/
$feed = Zend_Feed_Reader::import('http://example.com/feed');
$authors = $feed->getAuthors()->getValues();
]]></programlisting>
</sect2>
<sect2 id="migration.110.zend.file.transfer">
<title>Zend_File_Transfer</title>
<sect3 id="migration.110.zend.file.transfer.files">
<title>Security change</title>
<para>
For security reasons <classname>Zend_File_Transfer</classname> does no longer store
the original mimetype and filesize which is given from the requesting client into
its internal storage. Instead the real values will be detected at initiation.
</para>
<para>
Additionally the original values within <varname>$_FILES</varname> will be
overridden within the real values at initiation. This makes also
<varname>$_FILES</varname> secure.
</para>
<para>
When you are in need of the original values you can either store them before
initiating <classname>Zend_File_Transfer</classname> or use the
<property>disableInfos</property> option at initiation. Note that this option is
useless when its given after initiation.
</para>
</sect3>
<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.filter.html-entities">
<title>Zend_Filter_HtmlEntities</title>
<para>
In order to default to a more secure character encoding,
<classname>Zend_Filter_HtmlEntities</classname> now defaults to <acronym>UTF-8</acronym>
instead of <acronym>ISO-8859-1</acronym>.
</para>
<para>
Additionally, because the actual mechanism is dealing with character encodings and not
character sets, two new methods have been added, <methodname>setEncoding()</methodname>
and <methodname>getEncoding()</methodname>. The previous methods
<methodname>setCharSet()</methodname> and <methodname>setCharSet()</methodname> are now
deprecated and proxy to the new methods. Finally, instead of using the protected members
directly within the <methodname>filter()</methodname> method, these members are
retrieved by their explicit accessors. If you were extending the filter in the past,
please check your code and unit tests to ensure everything still continues to work.
</para>
</sect2>
<sect2 id="migration.110.zend.filter.strip-tags">
<title>Zend_Filter_StripTags</title>
<para>
<classname>Zend_Filter_StripTags</classname> contains a flag,
<varname>commentsAllowed</varname>, that, in previous versions, allowed you to
optionally whitelist <acronym>HTML</acronym> comments in <acronym>HTML</acronym> text
filtered by the class. However, this opens code enabling the flag to
<acronym>XSS</acronym> attacks, particularly in Internet Explorer (which allows
specifying conditional functionality via <acronym>HTML</acronym> comments). Starting
in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
<varname>commentsAllowed</varname> flag no longer has any meaning, and all
<acronym>HTML</acronym> comments, including those containing other
<acronym>HTML</acronym> tags or nested commments, will be stripped from the final output
of the filter.
</para>
</sect2>
<sect2 id="migration.110.zend.translate">
<title>Zend_Translate</title>
<sect3 id="migration.110.zend.translate.xliff">
<title>Xliff adapter</title>
<para>
In past the Xliff adapter used the source string as message Id. According to the
Xliff standard the trans-unit Id should be used. This behaviour was corrected with
Zend Framework 1.10. Now the trans-unit Id is used as message Id per default.
</para>
<para>
But you can still get the incorrect and old behaviour by setting the
<property>useId</property> option to <constant>FALSE</constant>.
</para>
<programlisting language="php"><![CDATA[
$trans = new Zend_Translate(
'xliff', '/path/to/source', $locale, array('useId' => false)
);
]]></programlisting>
</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:
-->
|
