File: Zend_Controller-Migration.xml

package info (click to toggle)
zendframework 1.12.9%2Bdfsg-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie-kfreebsd
  • size: 133,584 kB
  • sloc: xml: 1,311,829; php: 570,173; sh: 170; makefile: 125; sql: 121
file content (725 lines) | stat: -rw-r--r-- 31,983 bytes parent folder | download | duplicates (2)
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
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
<sect1 id="zend.controller.migration">
    <title>Migracja z poprzednich wersji</title>

    <para>
        API komponentów MVC zmieniało się z biegiem czasu. Jeśli zacząłeś używać
        Zend Framework we wczesnej wersji, postępuj według poniższych wskazówek
        aby przeprowadzić migrację swoich skryptów aby używały nowej architektury.
    </para>

    <sect2 id="zend.controller.migration.fromoneohtoonesix">
        <title>Migracja z wersji 1.5.x do 1.6.0 lub nowszej</title>

        <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
            <title>Zmiany w interfejsie obiektu uruchamiającego</title>

            <para>
                Użytkownicy zwrócili naszą uwagę na fakt, że klasy
                <code>Zend_Controller_Front</code> oraz
                <code>Zend_Controller_Router_Route_Module</code> używały metod
                obiektu uruchamiającego, które nie były zdefiniowane w
                interfejsie tego obiektu.
                Dodaliśmy teraz do interfejsu poniższe trzy metody aby upewnić
                się, że własne obiekty uruchamiające będą poprawnie działać:
            </para>

            <itemizedlist>
                <listitem><para>
                    <code>getDefaultModule()</code>: metoda powinna zwracać
                    nazwę domyślnego modułu.
                </para></listitem>

                <listitem><para>
                    <code>getDefaultControllerName()</code>: metoda powinna
                    zwracać nazwę domyślnego kontrolera.
                </para></listitem>

                <listitem><para>
                    <code>getDefaultAction()</code>: metoda powinna zwracać
                    nazwę domyślnej akcji.
                </para></listitem>
            </itemizedlist>
        </sect3>
    </sect2>

    <sect2 id="zend.controller.migration.fromoneohtoonefive">
        <title>Migracja z wersji 1.0.x do 1.5.0 lub nowszej</title>

        <para>
            O ile większość z podstawowych funkcjonalności i cała udokumentowana
            funkcjonalność pozostały te same, to nastąpiła jedna istotna zmiana
            w jednej <emphasis>nieudokumentowanej</emphasis> funkcjonalności.
        </para>

        <para>
            Udokumentowanym sposobem tworzenia adresów URL w postaci camelCased
            jest użycie znaku separatora w nazwie akcji; domyślnie separatorem
            mogą być znaki '.' lub '-', jednak może to być skonfigurowane w
            obiekcie uruchamiającym. Obiekt uruchamiający zmienia litery w
            nazwie akcji na małe i używa separatorów aby otrzymać nazwę metody
            akcji w postaci camelCasing. Jednak z tego powodu, że funkcje PHP
            nie są wrażliwe na wielkość liter, <emphasis>mogłeś</emphasis> wciąż
            tworzyć adresy w postaci camelCasing, a obiekt uruchamiający wciąż
            otrzymywał na ich podstawie nazwę tej samej akcji. Na przykład adres
            'camel-cased' zostałby zamieniony przez obiekt uruchamiający na
            'camelCasedAction', a adres 'camelCased' na 'camelcasedAction';
            z tego powodu że PHP nie jest wrażliwe na wielkość liter, w obu
            przypadkach zostanie uruchomiona ta sama metoda.
        </para>

        <para>
            Powoduje to problemy w klasie ViewRenderer gdy szuka ona skryptów
            widoku. Podstawowym udokumentowanym sposobem jest zastępowanie
            wszystkich separatorów wyrazów znakiem podkreślenia oraz zmiana
            liter na małe. Wprowadza to niezgodność semantyczną pomiędzy akcjami
            a skryptami widoków, a regulacja tego pozwoli na znajdowanie
            skryptów widoków w każdej sytuacji. Teraz jeśli wywołamy metodę
            'camelCased', separator wyrazów nie będzie już znajdować się w
            nazwie i ViewRenderer spróbuje uruchomić inny plik --
            'camelcased.phtml' zamiast 'camel-cased.phtml'.
        </para>

        <para>
            Niektórzy programiści polegali na tej "funkcjonalności", która nigdy
            nie była zamierzona. Wiele zmian w wersji 1.5.0 spowodowało, że
            klasa ViewRenderer nie znajduje już plików widoków w taki sposób;
            semnatyczna zgodność jest teraz wymuszona. Po pierwsze, obiekt
            uruchamiający wymusza teraz wrażliwość na wielkość liter w nazwach
            akcji. Oznacza to, że odwoływanie się do akcji używając w adresie
            formy camelCasing nie będzie już dłużej prowadzić do tej samej
            metody, do której prowadziło odwołanie za pomocą separatorów
            wyrazów (np., 'camel-casing'). Teraz klasa ViewRenderer podczas
            szukania skryptów widoku akceptuje jedynie formę z separatorami
            wyrazów.
        </para>

        <para>
            Jeśli okazało się, że polegałeś na tej "funkcjonalności", masz kilka
            rozwiązań:
        </para>

        <itemizedlist>
            <listitem><para>
                    Najlepsza opcja: zmień nazwy skwoich skryptów wiodku. Plus:
                    kompatybilność wsteczna. Minus: jeśli masz dużo skryptów
                    widoku, które polegają na tym niezamierzonym zachowaniu,
                    możesz mieć dużo plików do zmiany.
            </para></listitem>

            <listitem>
                <para>
                    Druga najlepsza opcja: klasa ViewRenderer teraz określa
                    nazwę skryptu widoku za pomocą klasy <code>Zend_Filter_Inflector</code>;
                    możesz zmodyfikować reguły określania nazwy, aby nie używać
                    separatorów wyrazów w nazwach akcji.
                </para>

                <programlisting role="php"><![CDATA[
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$inflector = $viewRenderer->getInflector();
$inflector->setFilterRule(':action', array(
    new Zend_Filter_PregReplace(
        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
        ''
    ),
    'StringToLower'
));
]]>
                </programlisting>

                <para>
                    Powyższy kod zmieni sposób określania nazwy skryptu widoku,
                    aby nie oddzielał słów za pomocą znaku podkreślenia; możesz
                    także usunać filtr 'StringToLower' jeśli
                    <emphasis>chcesz</emphasis> używać nazw skryptów widoku
                    w postaci camelCased.
                </para>

                <para>
                    Jeśli zmiana nazw skryptów widoku zajmie zbyt dużo czasu,
                    najlepszym sposobem będzie tymczasowe użycie powyższego kodu.
                </para>
            </listitem>

            <listitem>
                <para>
                    Najgorsza opcja: Możesz spowodować aby obiekt uruchamiający
                    uruchamiał akcje w postaci camelCased za pomocą nowej flagi
                    kontrolera frontowego, 'useCaseSensitiveActions':
                </para>

                <programlisting role="php"><![CDATA[
$front->setParam('useCaseSensitiveActions', true);
]]>
                </programlisting>

                <para>
                    Pozwoli ci to wciąż używać formy camelCasing w adresach URL
                    i taie wywołanie będzie uruchamiać tę samą akcję jak podczas
                    użycia separatorów wyrazów. Jednak oznacza to, że oryginalny
                    błąd będzie wciąż występował; jeśli nie chcesz aby wystąpiły
                    problemy, użyj przynajmniej drugiej z przedstawionych opcji.
                </para>

                <para>
                    Zauważ też, że użycie tej flagi spowoduje wyświetlenie
                    informacji o tym, że jej użycie jest przestarzałe.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninethree">
        <title>Migracja z wersji 0.9.3 do 1.0.0RC1 lub nowszej</title>

        <para>
            Głównymi zmianami, jakie pojawiły się w wersji 1.0.0RC1 jest dodanie
            i domyśle włączenie wtyczki <link
                linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
            oraz pomocniczej klasy akcji <link
                linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>.
            Proszę przeczytaj uważnie dokumentację obu komponentów aby dowiedzieć
            się jak one działają i jakie efekty mogą one mieć w twoich aplikacjach.
        </para>

        <para>
            Wtyczka <code>ErrorHandler</code> jest uruchamiana jako metoda
            <code>postDispatch()</code> w celu sprawdzenia czy wyrzucone zostały
            wyjątki i ewentualnego przeniesienia żądania do określonego kontrolera
            obsługi błędów. Powinieneś mieć taki kontroler w swojej aplikacji.
            Możesz jednak wyłączyć taką obsługę błędów ustawiając w kontrolerze
            frontowym parametr <code>noErrorHandler</code>:
        </para>

        <programlisting role="php"><![CDATA[
$front->setParam('noErrorHandler', true);
]]>
        </programlisting>

        <para>
            Pomocnicza klasa akcji <code>ViewRenderer</code> automatyzuje
            przekazywanie widoków do kontrolerów akcji oraz automatycznie
            renderuje skrypty widoku oparte na nazwie danej akcji. Głównym
            problemem jaki możesz napotkać są akcje, które nie renderują
            skryptów widoków, nie przekierowują i nie przenoszą żądania, z tego
            względu, że klasa <code>ViewRenderer</code> będzie próbować
            renderować skrypt widoku oparty na nazwie akcji.
        </para>

        <para>
            Jest kilka strategii które możesz podjąc aby zaktualizować swój kod.
            Krótkoterminowo możesz globalnie wyłączyć użycie klasy
            <code>ViewRenderer</code> w kontrolerze frontowym w pliku uruchamiającym
            przed uruchomieniem żądania:
        </para>

        <programlisting role="php"><![CDATA[
// Zakładając, że $front jest instancją klasy Zend_Controller_Front
$front->setParam('noViewRenderer', true);
]]>
        </programlisting>

        <para>
            Jednak długoterminowo nie jest to dobra strategia, ponieważ będziesz
            musiał pisać więcej kodu.
        </para>

        <para>
            Kiedy będziesz gotowy do użycia funkcjonalności klasy <code>ViewRenderer</code>,
            będzie kilka rzeczy które będziesz musiał sprawdzić w kodzie swoich kontrolerów.

            Wpierw spójrz na metody akcji (metody kończące się na 'Action') i
            sprawdź co one robią. Będziesz musiał wprowadzić zmiany, jeśli w
            metodzie nie jest przeprowadzana żadna z poniższych czynności:
        </para>

        <itemizedlist>
            <listitem><para>Wywołanie metody <code>$this-&gt;render()</code></para></listitem>
            <listitem><para>Wywołanie metody <code>$this-&gt;_forward()</code></para></listitem>
            <listitem><para>Wywołanie metody <code>$this-&gt;_redirect()</code></para></listitem>
            <listitem><para>Wywołanie pomocniczej klasy akcji <code>Redirector</code></para></listitem>
        </itemizedlist>

        <para>
            Najprostszym sposobem jest wyłączenie automatycznego renderowania dla tej metody:
        </para>

        <programlisting role="php"><![CDATA[
$this->_helper->viewRenderer->setNoRender();
]]>
        </programlisting>

        <para>
            Jeśli żadna z twoich akcji nie renderuje, nie przenosi i nie
            przekierowuje, możesz powyższą linię umieścić w metodzie
            <code>preDispatch()</code> lub <code>init()</code>:
        </para>

        <programlisting role="php"><![CDATA[
public function preDispatch()
{
    // wyłączamy automatyczne renderowanie skryptu widoku
    $this->_helper->viewRenderer->setNoRender()
    // .. robimy coś dalej...
}]]>
        </programlisting>

        <para>
            Jeśli wywołujesz metodę <code>render()</code>,
            i używasz <link
                linkend="zend.controller.modular">klasycznej modularnej struktury
                katalogów</link>,
            możesz potrzebować zaktualizować swój kod aby używał automatycznego
            renderowania:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Jeśli renderujesz wiele skryptów widoków w jednej akcji,
                    nie musisz nic zmieniać w tej kwestii.
                </para>
            </listitem>
            <listitem>
                <para>
                    Jeśli wywołujesz metodę <code>render()</code> bez argumentów,
                    możesz po prostu usunąć te wywołania.
                </para>
            </listitem>
            <listitem>
                <para>
                    Jeśli wywołujesz metodę <code>render()</code> używając
                    argumentów i nie wykonujesz później innego kodu ani nie
                    renderujesz kolejnych skryptów widoku, możesz zmienić
                    wywołania aby korzystały z metody o tej samej nazwie, obiektu
                    <code>$this-&gt;_helper-&gt;viewRenderer()</code>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Jeśli nie używasz klasycznej modularnej struktury katalogów, jest
            wiele sposobów ustawienia bazowej ścieżki widoków i specyfikacji
            ścieżek skryptów, do czego możesz użyć klasy <code>ViewRenderer</code>.
            Proszę przeczytaj <link
                linkend="zend.controller.actionhelpers.viewrenderer">dokumentację
                klasy ViewRenderer</link> aby uzyskać więcej informacji na
                temat tych metod.
        </para>

        <para>
            Jeśli używasz obiektu widoku z rejestru, konfigurujesz swój własny
            obiekt lub używasz innej implementacji widoku, możesz przekazać ten
            obiekt do obiektu <code>ViewRenderer</code>. Możesz to łatwo zrobić
            w dowolnym momencie.
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Przed uruchomieniem kontrolera frontowego:
                </para>

                <programlisting role="php"><![CDATA[
// Zakładając, że obiekt $view został już zdefiniowany
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
]]>
                </programlisting>
            </listitem>

            <listitem>
                <para>
                    W dowolnej chwili podczas procesu ładowania:
                </para>

                <programlisting role="php"><![CDATA[
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer->setView($view);
]]>
                </programlisting>
            </listitem>
        </itemizedlist>

        <para>
            Jest wiele sposobów na zmodyfikowanie obiektu <code>ViewRenderer</code>,
            włączając w to ustawienie innego skryptu widoku do renderowania,
            zastąpienie wszystkich części ścieżki skrytu widoku (także przyrostka),
            wybranie segmentu obiektu odpowiedzi w którym ma być zrenderowany
            i kilka innych. Jeśli nie chcesz używać klasycznej modularnej
            struktury katalogów, możesz określić inne specyfikacje ścieżek za
            pomocą klasy <code>ViewRenderer</code>.
        </para>

        <para>
            Zalecamy zaadaptowanie w swoim kodzie użycia wtyczki
            <code>ErrorHandler</code> oraz pomocniczej klasy akcji
            <code>ViewRenderer</code> z tego względu, że te funkcjonalności są
            teraz składnikiem jądra.
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzeroninetwo">
        <title>Migracja z wersji 0.9.2 do 0.9.3 lub nowszej</title>

        <para>
            W wersji 0.9.3 pojawiają się <link
            linkend="zend.controller.actionhelpers">klasy pomocnicze akcji</link>.
            W związku z tym, poniższe metody zostały usunięte, z tego względu, że
            teraz są one zawarte w <link
            linkend="zend.controller.actionhelpers.redirector">przekierowującej
            pomocniczej klasie akcji</link>:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <code>setRedirectCode()</code>; użyj
                    <code>Zend_Controller_Action_Helper_Redirector::setCode()</code>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectPrependBase()</code>; użyj
                    <code>Zend_Controller_Action_Helper_Redirector::setPrependBase()</code>.
                </para>
            </listitem>
            <listitem>
                <para>
                    <code>setRedirectExit()</code>; użyj
                    <code>Zend_Controller_Action_Helper_Redirector::setExit()</code>.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            Przeczytaj <link linkend="zend.controller.actionhelpers">dokumentację
            pomocniczych klas akcji</link> aby uzyskać więcej informacji o tym
            jak można pobrać obiekty pomocnicze i jak nimi manipulować, oraz dokumentację
            <link linkend="zend.controller.actionhelpers.redirector">przekierowującej
            pomocniczej klasy akcji</link> w celu uzyskania informacji o ustawianiu
            opcji przekierowania (a także o innych metodach dla przekierowań).
        </para>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerosix">
        <title>Migracja z wersji 0.6.0 do 0.8.0 lub nowszej</title>

        <para>
            Od czasu poprzednich zmian, najbardziej podstawowe użycie
            komponentów MVC pozostaje takie same:
        </para>

        <programlisting role="php"><![CDATA[
Zend_Controller_Front::run('/path/to/controllers');
]]>
        </programlisting>

        <para>
            Jakkolwiek, struktura katalogów została przebudowana, kilka
            komponentów usunięto, kilku innym zmieniono nazwy, a także kilka
            dodano. Zmiany to:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    Klasa <code>Zend_Controller_Router</code> została usunięta
                    na rzecz rewrite routera.
                </para>
            </listitem>

            <listitem>
                <para>
                    Nazwa klasy <code>Zend_Controller_RewriteRouter</code>
                    została zmieniona na <code>Zend_Controller_Router_Rewrite</code>
                    i awansowała ona na standardowy router dostarczany z frameworkiem;
                    <code>Zend_Controller_Front</code> użyje go domyślnie, jeśli
                    żaden inny router nie zostanie ustawiony.
                </para>
            </listitem>

            <listitem>
                <para>
                    Nowa klasa trasy doa użycia z rewrite routerem została
                    przedstawiona, jest to
                    <code>Zend_Controller_Router_Route_Module</code>; kryje
                    ona w sobie domyślną trasę używaną przez MVC i wspiera <link
                        linkend="zend.controller.modular">moduły
                        kontrolerów</link>.
                </para>
            </listitem>

            <listitem>
                <para>
                    Nazwa klasy <code>Zend_Controller_Router_StaticRoute</code>
                    została zmieniona na
                    <code>Zend_Controller_Router_Route_Static</code>.
                </para>
            </listitem>

            <listitem>
                <para>
                    Nazwa klasy <code>Zend_Controller_Dispatcher</code> została
                    zmieniona na <code>Zend_Controller_Dispatcher_Standard</code>.
                </para>
            </listitem>

            <listitem>
                <para>
                    Zmieniły się argumenty metody
                    <code>Zend_Controller_Action::_forward()</code>. Sygnatura
                    wygląda teraz następująco:
                </para>

                <programlisting role="php"><![CDATA[
final protected function _forward($action, $controller = null, $module = null, array $params = null);
]]>
                </programlisting>

                <para>
                    Parametr <code>$action</code> jest zawsze wymagany; jeśli
                    kontroler nie jest określony, to brana pod uwagę jest akcja
                    z obecnego kontrolera. Parametr <code>$module</code> jest
                    zawsze ignorowany, o ile parametr <code>$controller</code>
                    nie jest określony. Ostatecznie każdy z parametrów w
                    tablicy <code>$params</code> będzie dołączony do obiektu
                    żądania. Jeśli nie potrzebujesz określić kontrolera lub
                    modułu, ale potrzebujesz przekazać parametry, po prostu
                    określ te wartości jako null.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>

    <sect2 id="zend.controller.migration.fromzerotwo">
        <title>Migracja z wersji 0.2.0 lub z poprzednich do 0.6.0</title>

        <para>
            Podstawowy sposób korzystania z komponentów MVC nie zmienił się;
            nadal możesz użyć poniższego kodu:
        </para>

        <programlisting role="php"><![CDATA[
Zend_Controller_Front::run('/path/to/controllers');
]]>
        </programlisting>

        <programlisting role="php"><![CDATA[
/* -- utwórz router -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user', 'user/:username', array('controller' => 'user',
'action' => 'info'));

/* -- ustawić go w kontrolerze -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- ustawić katalog kontrolerów i uruchomić -- */
$ctrl->setControllerDirectory('/path/to/controllers');
$ctrl->dispatch();
]]>
        </programlisting>

        <para>
            Zalecamy użycie obiektu odpowiedzi (Response) do łączenia zawartości
            i nagłówków. To pozwala na bardziej elastyczne zmiany formatu danych
            wyjściowych (na przykład JSON lub XML zamiast XHTML) w twoich
            aplikacjach. Domyślnie metoda <code>dispatch()</code> zrenderuje
            całą odpowiedź, wyśle nagłówki i całą zawartość. Możesz także
            użyć kontrolera frontowego aby zwrócił zawartość za pomocą metody
            <code>returnResponse()</code>, a potem zrenderować odpowiedź używając
            twojej własnej logiki. Przyszłe wersje kontrolera frontowego mogą
            forsować użycie obiektu odpowiedzi przez wyświetlenie danych
            wyjściowych.
        </para>

        <para>
            Jest wiele dodatkowych funkcjonalności, które rozszerzają istniejące
            API i są one opisane w dokumentacji.
        </para>

        <para>
            Główne zmiany, na które musisz uważać, nastąpiły przy tworzeniu klas
            pochodnych komponentów. Te zmiany to:
        </para>

        <itemizedlist>
            <listitem>
                <para>
                    <code>Zend_Controller_Front::dispatch()</code> domyślnie
                    łapie wyjątki w obiekcie odpowiedzi i nie renderuje ich
                    aby zapobiec wyświetlaniu ważnych informacji systemowych.
                    Możesz zmienić to zachowanie na kilka sposobów:
                </para>

                <itemizedlist>
                    <listitem>
                        <para>
                            Ustaw <code>throwExceptions()</code> w kontrolerze
                            frontowym:
                        </para>
                        <programlisting role="php"><![CDATA[
$front->throwExceptions(true);
]]>
                        </programlisting>
                    </listitem>

                    <listitem>
                        <para>
                            Ustaw <code>renderExceptions()</code> w obiekcie
                            odpowiedzi:
                        </para>
                        <programlisting role="php"><![CDATA[
$response->renderExceptions(true);
$front->setResponse($response);
$front->dispatch();

// lub:
$front->returnResponse(true);
$response = $front->dispatch();
$response->renderExceptions(true);
echo $response;
]]>
                        </programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem><para>
                <code>Zend_Controller_Dispatcher_Interface::dispatch()</code>
                zamiast tokena dispatchera przyjmuje i zwraca teraz
                obiekt <xref linkend="zend.controller.request" />.
            </para></listitem>

            <listitem><para>
                <code>Zend_Controller_Router_Interface::route()</code>
                przyjmuje i zwraca obiekt <xref linkend="zend.controller.request" />
                zamiast tokena dispatchera.
            </para></listitem>

            <listitem>
                <para>Zmiany w <code>Zend_Controller_Action</code> to:</para>

                <itemizedlist>
                    <listitem><para>
                        Kontruktor teraz przyjmuje dokładnie trzy argumenty,
                        <code>Zend_Controller_Request_Abstract $request</code>,
                        <code>Zend_Controller_Response_Abstract $response</code>,
                        oraz <code>array $params (opcjonalny)</code>.
                        <code>Zend_Controller_Action::__construct()</code> używa
                        ich aby ustawić żądanie, odpowiedź, i właściwości
                        invokeArgs obiektu i jeśli nadpisujesz konstruktor,
                        powinieneś je także ustawić. Lepiej jednak użyj
                        metody <code>init()</code> aby skonfigurować instancję,
                        ponieważ ta metoda jest wywoływana jako ostatnia akcja
                        konstruktora.
                    </para></listitem>

                    <listitem><para>
                        Metoda <code>run()</code> nie jest już zdefiniowana jako finalna,
                        ale nie jest też już używana przez kontroler frontowy;
                        Jej jedynym celem jest użycie klasy jako kontrolera strony.
                        Przyjmuje ona teraz dwa opcjonalne argumenty,
                        <code>Zend_Controller_Request_Abstract $request</code>
                        oraz <code>Zend_Controller_Response_Abstract $response</code>.
                    </para></listitem>

                    <listitem><para>
                        Akcja <code>indexAction()</code> nie musi być już
                        zdefiniowana, ale jest zalecana jako domyślna akcja.
                        To pozwala routerowi RewriteRouter oraz kontrolerom akcji
                        na określenie innych domyślnych metod akcji.
                    </para></listitem>

                    <listitem><para>
                        Metoda <code>__call()</code> powinna być nadpisana aby
                        obsłużyć automatycznie niezdefiniowane akcje.
                    </para></listitem>

                    <listitem><para>
                        Metoda <code>_redirect()</code> przyjmuje teraz opcjonalny
                        drugi argument, kod HTTP, który ma być zwrócony z
                        przekierowaniem oraz opcjonalny trzeci argument,
                        <code>$prependBase</code>, który może zdecydować czy
                        bazowy adres URL zarejestrowany w obiekcie żądania ma być
                        dodany do adresu URL.
                    </para></listitem>

                    <listitem>
                        <para>
                            Właściwość <code>_action</code> nie jest już
                            zdefiniowana. Ta właściwość była obiektem
                            <code>Zend_Controller_Dispatcher_Token</code>, który
                            nie istnieje już w aktualnej wersji. Jedynym
                            zastosowaniem tokena było przechowanie informacji o
                            zażądanym kontrolerze, akcji i parametrach URL. Te
                            informacje są teraz dostępne w obiekcie żądania w
                            taki sposób:
                        </para>

                        <programlisting role="php"><![CDATA[
// Pobierz nazwę kontrolera z żądania
// Dotychczas dostęp do niej był za pomocą: $this->_action->getControllerName().
// Poniższy przykład używa metody getRequest(), ale możesz także bezpośrednio
// użyć właściwości $_request; użycie getRequest() jest zalecane ponieważ klasa
// rodzica może nadpisać dostęp do obiektu żądania.
$controller = $this->getRequest()->getControllerName();

// Pobierz nazwę akcji z żądania
// Dotychczas dostęp do niej był za pomocą: $this->_action->getActionName().
$action = $this->getRequest()->getActionName();

// Pobierz parametry z żądania
// To się nie zmieniło; metody _getParams() oraz _getParam() teraz w prosty
// sposób wskazują na obiekt żądania.
$params = $this->_getParams();
$foo = $this->_getParam('foo', 'default'); // pobierz parametr 'foo', używając
                                           // wartości 'default' jako domyślnej
]]>
                        </programlisting>
                    </listitem>

                    <listitem>
                        <para>
                            Metoda <code>noRouteAction()</code> została usunięta.
                            Aby w poprawny sposób obsługiwać nieistniejące
                            metody akcji powinieneś przekierować je do domyślnej
                            akcji używając metody <code>__call()</code>:
                        </para>

                        <programlisting role="php"><![CDATA[
public function __call($method, $args)
{
    // Jeśli została zażądania nieistniejąca metoda 'Action', żądanie zostanie
    // przekazane do domyślnej metody akcji:
    if ('Action' == substr($method, -6)) {
        return $this->defaultAction();
    }

    throw new Zend_Controller_Exception('Nieprawdiłowa metoda');
}
]]>
                        </programlisting>
                    </listitem>
                </itemizedlist>
            </listitem>

            <listitem><para>
                Akcja <code>Zend_Controller_RewriteRouter::setRewriteBase()</code>
                została usunięta. W zamian użyj
                <code>Zend_Controller_Front::setBaseUrl()</code>
                (lub Zend_Controller_Request_Http::setBaseUrl(), jeśli używasz
                tej klasy).
            </para></listitem>

            <listitem><para>
                Interfejs <code>Zend_Controller_Plugin_Interface</code> został
                zamieniony na <code>Zend_Controller_Plugin_Abstract</code>.
                Wszystkie metody przyjmują i zwracają obiekt
                <xref linkend="zend.controller.request" />
                zamiast tokena dispatchera.
            </para></listitem>
        </itemizedlist>
    </sect2>
</sect1>