| blob | 8b440178573791bbccb087ca4f1426187b4d5cc3 |
1 <sect1 id="zend.controller.migration">
2 <title>Migracja z poprzednich wersji</title>
4 <para>
5 API komponentów MVC zmieniało się z biegiem czasu. Jeśli zacząłeś używać
6 Zend Framework we wczesnej wersji, postępuj według poniższych wskazówek
7 aby przeprowadzić migrację swoich skryptów aby używały nowej architektury.
8 </para>
10 <sect2 id="zend.controller.migration.fromoneohtoonesix">
11 <title>Migracja z wersji 1.5.x do 1.6.0 lub nowszej</title>
13 <sect3 id="zend.controller.migration.fromoneohtoonesix.dispatcher">
14 <title>Zmiany w interfejsie obiektu uruchamiającego</title>
16 <para>
17 Użytkownicy zwrócili naszą uwagę na fakt, że klasy
18 <code>Zend_Controller_Front</code> oraz
19 <code>Zend_Controller_Router_Route_Module</code> używały metod
20 obiektu uruchamiającego, które nie były zdefiniowane w
21 interfejsie tego obiektu.
22 Dodaliśmy teraz do interfejsu poniższe trzy metody aby upewnić
23 się, że własne obiekty uruchamiające będą poprawnie działać:
24 </para>
26 <itemizedlist>
27 <listitem><para>
28 <code>getDefaultModule()</code>: metoda powinna zwracać
29 nazwę domyślnego modułu.
30 </para></listitem>
32 <listitem><para>
33 <code>getDefaultControllerName()</code>: metoda powinna
34 zwracać nazwę domyślnego kontrolera.
35 </para></listitem>
37 <listitem><para>
38 <code>getDefaultAction()</code>: metoda powinna zwracać
39 nazwę domyślnej akcji.
40 </para></listitem>
41 </itemizedlist>
42 </sect3>
43 </sect2>
45 <sect2 id="zend.controller.migration.fromoneohtoonefive">
46 <title>Migracja z wersji 1.0.x do 1.5.0 lub nowszej</title>
48 <para>
49 O ile większość z podstawowych funkcjonalności i cała udokumentowana
50 funkcjonalność pozostały te same, to nastąpiła jedna istotna zmiana
51 w jednej <emphasis>nieudokumentowanej</emphasis> funkcjonalności.
52 </para>
54 <para>
55 Udokumentowanym sposobem tworzenia adresów URL w postaci camelCased
56 jest użycie znaku separatora w nazwie akcji; domyślnie separatorem
57 mogą być znaki '.' lub '-', jednak może to być skonfigurowane w
58 obiekcie uruchamiającym. Obiekt uruchamiający zmienia litery w
59 nazwie akcji na małe i używa separatorów aby otrzymać nazwę metody
60 akcji w postaci camelCasing. Jednak z tego powodu, że funkcje PHP
61 nie są wrażliwe na wielkość liter, <emphasis>mogłeś</emphasis> wciąż
62 tworzyć adresy w postaci camelCasing, a obiekt uruchamiający wciąż
63 otrzymywał na ich podstawie nazwę tej samej akcji. Na przykład adres
64 'camel-cased' zostałby zamieniony przez obiekt uruchamiający na
65 'camelCasedAction', a adres 'camelCased' na 'camelcasedAction';
66 z tego powodu że PHP nie jest wrażliwe na wielkość liter, w obu
67 przypadkach zostanie uruchomiona ta sama metoda.
68 </para>
70 <para>
71 Powoduje to problemy w klasie ViewRenderer gdy szuka ona skryptów
72 widoku. Podstawowym udokumentowanym sposobem jest zastępowanie
73 wszystkich separatorów wyrazów znakiem podkreślenia oraz zmiana
74 liter na małe. Wprowadza to niezgodność semantyczną pomiędzy akcjami
75 a skryptami widoków, a regulacja tego pozwoli na znajdowanie
76 skryptów widoków w każdej sytuacji. Teraz jeśli wywołamy metodę
77 'camelCased', separator wyrazów nie będzie już znajdować się w
78 nazwie i ViewRenderer spróbuje uruchomić inny plik --
79 'camelcased.phtml' zamiast 'camel-cased.phtml'.
80 </para>
82 <para>
83 Niektórzy programiści polegali na tej "funkcjonalności", która nigdy
84 nie była zamierzona. Wiele zmian w wersji 1.5.0 spowodowało, że
85 klasa ViewRenderer nie znajduje już plików widoków w taki sposób;
86 semnatyczna zgodność jest teraz wymuszona. Po pierwsze, obiekt
87 uruchamiający wymusza teraz wrażliwość na wielkość liter w nazwach
88 akcji. Oznacza to, że odwoływanie się do akcji używając w adresie
89 formy camelCasing nie będzie już dłużej prowadzić do tej samej
90 metody, do której prowadziło odwołanie za pomocą separatorów
91 wyrazów (np., 'camel-casing'). Teraz klasa ViewRenderer podczas
92 szukania skryptów widoku akceptuje jedynie formę z separatorami
93 wyrazów.
94 </para>
96 <para>
97 Jeśli okazało się, że polegałeś na tej "funkcjonalności", masz kilka
98 rozwiązań:
99 </para>
101 <itemizedlist>
102 <listitem><para>
103 Najlepsza opcja: zmień nazwy skwoich skryptów wiodku. Plus:
104 kompatybilność wsteczna. Minus: jeśli masz dużo skryptów
105 widoku, które polegają na tym niezamierzonym zachowaniu,
106 możesz mieć dużo plików do zmiany.
107 </para></listitem>
109 <listitem>
110 <para>
111 Druga najlepsza opcja: klasa ViewRenderer teraz określa
112 nazwę skryptu widoku za pomocą klasy <code>Zend_Filter_Inflector</code>;
113 możesz zmodyfikować reguły określania nazwy, aby nie używać
114 separatorów wyrazów w nazwach akcji.
115 </para>
117 <programlisting role="php"><![CDATA[
118 $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
119 $inflector = $viewRenderer->getInflector();
120 $inflector->setFilterRule(':action', array(
121 new Zend_Filter_PregReplace(
122 '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
123 ''
124 ),
125 'StringToLower'
126 ));
127 ]]>
128 </programlisting>
130 <para>
131 Powyższy kod zmieni sposób określania nazwy skryptu widoku,
132 aby nie oddzielał słów za pomocą znaku podkreślenia; możesz
133 także usunać filtr 'StringToLower' jeśli
134 <emphasis>chcesz</emphasis> używać nazw skryptów widoku
135 w postaci camelCased.
136 </para>
138 <para>
139 Jeśli zmiana nazw skryptów widoku zajmie zbyt dużo czasu,
140 najlepszym sposobem będzie tymczasowe użycie powyższego kodu.
141 </para>
142 </listitem>
144 <listitem>
145 <para>
146 Najgorsza opcja: Możesz spowodować aby obiekt uruchamiający
147 uruchamiał akcje w postaci camelCased za pomocą nowej flagi
148 kontrolera frontowego, 'useCaseSensitiveActions':
149 </para>
151 <programlisting role="php"><![CDATA[
152 $front->setParam('useCaseSensitiveActions', true);
153 ]]>
154 </programlisting>
156 <para>
157 Pozwoli ci to wciąż używać formy camelCasing w adresach URL
158 i taie wywołanie będzie uruchamiać tę samą akcję jak podczas
159 użycia separatorów wyrazów. Jednak oznacza to, że oryginalny
160 błąd będzie wciąż występował; jeśli nie chcesz aby wystąpiły
161 problemy, użyj przynajmniej drugiej z przedstawionych opcji.
162 </para>
164 <para>
165 Zauważ też, że użycie tej flagi spowoduje wyświetlenie
166 informacji o tym, że jej użycie jest przestarzałe.
167 </para>
168 </listitem>
169 </itemizedlist>
170 </sect2>
172 <sect2 id="zend.controller.migration.fromzeroninethree">
173 <title>Migracja z wersji 0.9.3 do 1.0.0RC1 lub nowszej</title>
175 <para>
176 Głównymi zmianami, jakie pojawiły się w wersji 1.0.0RC1 jest dodanie
177 i domyśle włączenie wtyczki <link
178 linkend="zend.controller.plugins.standard.errorhandler">ErrorHandler</link>
179 oraz pomocniczej klasy akcji <link
180 linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>.
181 Proszę przeczytaj uważnie dokumentację obu komponentów aby dowiedzieć
182 się jak one działają i jakie efekty mogą one mieć w twoich aplikacjach.
183 </para>
185 <para>
186 Wtyczka <code>ErrorHandler</code> jest uruchamiana jako metoda
187 <code>postDispatch()</code> w celu sprawdzenia czy wyrzucone zostały
188 wyjątki i ewentualnego przeniesienia żądania do określonego kontrolera
189 obsługi błędów. Powinieneś mieć taki kontroler w swojej aplikacji.
190 Możesz jednak wyłączyć taką obsługę błędów ustawiając w kontrolerze
191 frontowym parametr <code>noErrorHandler</code>:
192 </para>
194 <programlisting role="php"><![CDATA[
195 $front->setParam('noErrorHandler', true);
196 ]]>
197 </programlisting>
199 <para>
200 Pomocnicza klasa akcji <code>ViewRenderer</code> automatyzuje
201 przekazywanie widoków do kontrolerów akcji oraz automatycznie
202 renderuje skrypty widoku oparte na nazwie danej akcji. Głównym
203 problemem jaki możesz napotkać są akcje, które nie renderują
204 skryptów widoków, nie przekierowują i nie przenoszą żądania, z tego
205 względu, że klasa <code>ViewRenderer</code> będzie próbować
206 renderować skrypt widoku oparty na nazwie akcji.
207 </para>
209 <para>
210 Jest kilka strategii które możesz podjąc aby zaktualizować swój kod.
211 Krótkoterminowo możesz globalnie wyłączyć użycie klasy
212 <code>ViewRenderer</code> w kontrolerze frontowym w pliku uruchamiającym
213 przed uruchomieniem żądania:
214 </para>
216 <programlisting role="php"><![CDATA[
217 // Zakładając, że $front jest instancją klasy Zend_Controller_Front
218 $front->setParam('noViewRenderer', true);
219 ]]>
220 </programlisting>
222 <para>
223 Jednak długoterminowo nie jest to dobra strategia, ponieważ będziesz
224 musiał pisać więcej kodu.
225 </para>
227 <para>
228 Kiedy będziesz gotowy do użycia funkcjonalności klasy <code>ViewRenderer</code>,
229 będzie kilka rzeczy które będziesz musiał sprawdzić w kodzie swoich kontrolerów.
231 Wpierw spójrz na metody akcji (metody kończące się na 'Action') i
232 sprawdź co one robią. Będziesz musiał wprowadzić zmiany, jeśli w
233 metodzie nie jest przeprowadzana żadna z poniższych czynności:
234 </para>
236 <itemizedlist>
237 <listitem><para>Wywołanie metody <code>$this->render()</code></para></listitem>
238 <listitem><para>Wywołanie metody <code>$this->_forward()</code></para></listitem>
239 <listitem><para>Wywołanie metody <code>$this->_redirect()</code></para></listitem>
240 <listitem><para>Wywołanie pomocniczej klasy akcji <code>Redirector</code></para></listitem>
241 </itemizedlist>
243 <para>
244 Najprostszym sposobem jest wyłączenie automatycznego renderowania dla tej metody:
245 </para>
247 <programlisting role="php"><![CDATA[
248 $this->_helper->viewRenderer->setNoRender();
249 ]]>
250 </programlisting>
252 <para>
253 Jeśli żadna z twoich akcji nie renderuje, nie przenosi i nie
254 przekierowuje, możesz powyższą linię umieścić w metodzie
255 <code>preDispatch()</code> lub <code>init()</code>:
256 </para>
258 <programlisting role="php"><![CDATA[
259 public function preDispatch()
260 {
261 // wyłączamy automatyczne renderowanie skryptu widoku
262 $this->_helper->viewRenderer->setNoRender()
263 // .. robimy coś dalej...
264 }]]>
265 </programlisting>
267 <para>
268 Jeśli wywołujesz metodę <code>render()</code>,
269 i używasz <link
270 linkend="zend.controller.modular">klasycznej modularnej struktury
271 katalogów</link>,
272 możesz potrzebować zaktualizować swój kod aby używał automatycznego
273 renderowania:
274 </para>
276 <itemizedlist>
277 <listitem>
278 <para>
279 Jeśli renderujesz wiele skryptów widoków w jednej akcji,
280 nie musisz nic zmieniać w tej kwestii.
281 </para>
282 </listitem>
283 <listitem>
284 <para>
285 Jeśli wywołujesz metodę <code>render()</code> bez argumentów,
286 możesz po prostu usunąć te wywołania.
287 </para>
288 </listitem>
289 <listitem>
290 <para>
291 Jeśli wywołujesz metodę <code>render()</code> używając
292 argumentów i nie wykonujesz później innego kodu ani nie
293 renderujesz kolejnych skryptów widoku, możesz zmienić
294 wywołania aby korzystały z metody o tej samej nazwie, obiektu
295 <code>$this->_helper->viewRenderer()</code>.
296 </para>
297 </listitem>
298 </itemizedlist>
300 <para>
301 Jeśli nie używasz klasycznej modularnej struktury katalogów, jest
302 wiele sposobów ustawienia bazowej ścieżki widoków i specyfikacji
303 ścieżek skryptów, do czego możesz użyć klasy <code>ViewRenderer</code>.
304 Proszę przeczytaj <link
305 linkend="zend.controller.actionhelpers.viewrenderer">dokumentację
306 klasy ViewRenderer</link> aby uzyskać więcej informacji na
307 temat tych metod.
308 </para>
310 <para>
311 Jeśli używasz obiektu widoku z rejestru, konfigurujesz swój własny
312 obiekt lub używasz innej implementacji widoku, możesz przekazać ten
313 obiekt do obiektu <code>ViewRenderer</code>. Możesz to łatwo zrobić
314 w dowolnym momencie.
315 </para>
317 <itemizedlist>
318 <listitem>
319 <para>
320 Przed uruchomieniem kontrolera frontowego:
321 </para>
323 <programlisting role="php"><![CDATA[
324 // Zakładając, że obiekt $view został już zdefiniowany
325 $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
326 Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
327 ]]>
328 </programlisting>
329 </listitem>
331 <listitem>
332 <para>
333 W dowolnej chwili podczas procesu ładowania:
334 </para>
336 <programlisting role="php"><![CDATA[
337 $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
338 $viewRenderer->setView($view);
339 ]]>
340 </programlisting>
341 </listitem>
342 </itemizedlist>
344 <para>
345 Jest wiele sposobów na zmodyfikowanie obiektu <code>ViewRenderer</code>,
346 włączając w to ustawienie innego skryptu widoku do renderowania,
347 zastąpienie wszystkich części ścieżki skrytu widoku (także przyrostka),
348 wybranie segmentu obiektu odpowiedzi w którym ma być zrenderowany
349 i kilka innych. Jeśli nie chcesz używać klasycznej modularnej
350 struktury katalogów, możesz określić inne specyfikacje ścieżek za
351 pomocą klasy <code>ViewRenderer</code>.
352 </para>
354 <para>
355 Zalecamy zaadaptowanie w swoim kodzie użycia wtyczki
356 <code>ErrorHandler</code> oraz pomocniczej klasy akcji
357 <code>ViewRenderer</code> z tego względu, że te funkcjonalności są
358 teraz składnikiem jądra.
359 </para>
360 </sect2>
362 <sect2 id="zend.controller.migration.fromzeroninetwo">
363 <title>Migracja z wersji 0.9.2 do 0.9.3 lub nowszej</title>
365 <para>
366 W wersji 0.9.3 pojawiają się <link
367 linkend="zend.controller.actionhelpers">klasy pomocnicze akcji</link>.
368 W związku z tym, poniższe metody zostały usunięte, z tego względu, że
369 teraz są one zawarte w <link
370 linkend="zend.controller.actionhelpers.redirector">przekierowującej
371 pomocniczej klasie akcji</link>:
372 </para>
374 <itemizedlist>
375 <listitem>
376 <para>
377 <code>setRedirectCode()</code>; użyj
378 <code>Zend_Controller_Action_Helper_Redirector::setCode()</code>.
379 </para>
380 </listitem>
381 <listitem>
382 <para>
383 <code>setRedirectPrependBase()</code>; użyj
384 <code>Zend_Controller_Action_Helper_Redirector::setPrependBase()</code>.
385 </para>
386 </listitem>
387 <listitem>
388 <para>
389 <code>setRedirectExit()</code>; użyj
390 <code>Zend_Controller_Action_Helper_Redirector::setExit()</code>.
391 </para>
392 </listitem>
393 </itemizedlist>
395 <para>
396 Przeczytaj <link linkend="zend.controller.actionhelpers">dokumentację
397 pomocniczych klas akcji</link> aby uzyskać więcej informacji o tym
398 jak można pobrać obiekty pomocnicze i jak nimi manipulować, oraz dokumentację
399 <link linkend="zend.controller.actionhelpers.redirector">przekierowującej
400 pomocniczej klasy akcji</link> w celu uzyskania informacji o ustawianiu
401 opcji przekierowania (a także o innych metodach dla przekierowań).
402 </para>
403 </sect2>
405 <sect2 id="zend.controller.migration.fromzerosix">
406 <title>Migracja z wersji 0.6.0 do 0.8.0 lub nowszej</title>
408 <para>
409 Od czasu poprzednich zmian, najbardziej podstawowe użycie
410 komponentów MVC pozostaje takie same:
411 </para>
413 <programlisting role="php"><![CDATA[
414 Zend_Controller_Front::run('/path/to/controllers');
415 ]]>
416 </programlisting>
418 <para>
419 Jakkolwiek, struktura katalogów została przebudowana, kilka
420 komponentów usunięto, kilku innym zmieniono nazwy, a także kilka
421 dodano. Zmiany to:
422 </para>
424 <itemizedlist>
425 <listitem>
426 <para>
427 Klasa <code>Zend_Controller_Router</code> została usunięta
428 na rzecz rewrite routera.
429 </para>
430 </listitem>
432 <listitem>
433 <para>
434 Nazwa klasy <code>Zend_Controller_RewriteRouter</code>
435 została zmieniona na <code>Zend_Controller_Router_Rewrite</code>
436 i awansowała ona na standardowy router dostarczany z frameworkiem;
437 <code>Zend_Controller_Front</code> użyje go domyślnie, jeśli
438 żaden inny router nie zostanie ustawiony.
439 </para>
440 </listitem>
442 <listitem>
443 <para>
444 Nowa klasa trasy doa użycia z rewrite routerem została
445 przedstawiona, jest to
446 <code>Zend_Controller_Router_Route_Module</code>; kryje
447 ona w sobie domyślną trasę używaną przez MVC i wspiera <link
448 linkend="zend.controller.modular">moduły
449 kontrolerów</link>.
450 </para>
451 </listitem>
453 <listitem>
454 <para>
455 Nazwa klasy <code>Zend_Controller_Router_StaticRoute</code>
456 została zmieniona na
457 <code>Zend_Controller_Router_Route_Static</code>.
458 </para>
459 </listitem>
461 <listitem>
462 <para>
463 Nazwa klasy <code>Zend_Controller_Dispatcher</code> została
464 zmieniona na <code>Zend_Controller_Dispatcher_Standard</code>.
465 </para>
466 </listitem>
468 <listitem>
469 <para>
470 Zmieniły się argumenty metody
471 <code>Zend_Controller_Action::_forward()</code>. Sygnatura
472 wygląda teraz następująco:
473 </para>
475 <programlisting role="php"><![CDATA[
476 final protected function _forward($action, $controller = null, $module = null, array $params = null);
477 ]]>
478 </programlisting>
480 <para>
481 Parametr <code>$action</code> jest zawsze wymagany; jeśli
482 kontroler nie jest określony, to brana pod uwagę jest akcja
483 z obecnego kontrolera. Parametr <code>$module</code> jest
484 zawsze ignorowany, o ile parametr <code>$controller</code>
485 nie jest określony. Ostatecznie każdy z parametrów w
486 tablicy <code>$params</code> będzie dołączony do obiektu
487 żądania. Jeśli nie potrzebujesz określić kontrolera lub
488 modułu, ale potrzebujesz przekazać parametry, po prostu
489 określ te wartości jako null.
490 </para>
491 </listitem>
492 </itemizedlist>
493 </sect2>
495 <sect2 id="zend.controller.migration.fromzerotwo">
496 <title>Migracja z wersji 0.2.0 lub z poprzednich do 0.6.0</title>
498 <para>
499 Podstawowy sposób korzystania z komponentów MVC nie zmienił się;
500 nadal możesz użyć poniższego kodu:
501 </para>
503 <programlisting role="php"><![CDATA[
504 Zend_Controller_Front::run('/path/to/controllers');
505 ]]>
506 </programlisting>
508 <programlisting role="php"><![CDATA[
509 /* -- utwórz router -- */
510 $router = new Zend_Controller_RewriteRouter();
511 $router->addRoute('user', 'user/:username', array('controller' => 'user',
512 'action' => 'info'));
514 /* -- ustawić go w kontrolerze -- */
515 $ctrl = Zend_Controller_Front::getInstance();
516 $ctrl->setRouter($router);
518 /* -- ustawić katalog kontrolerów i uruchomić -- */
519 $ctrl->setControllerDirectory('/path/to/controllers');
520 $ctrl->dispatch();
521 ]]>
522 </programlisting>
524 <para>
525 Zalecamy użycie obiektu odpowiedzi (Response) do łączenia zawartości
526 i nagłówków. To pozwala na bardziej elastyczne zmiany formatu danych
527 wyjściowych (na przykład JSON lub XML zamiast XHTML) w twoich
528 aplikacjach. Domyślnie metoda <code>dispatch()</code> zrenderuje
529 całą odpowiedź, wyśle nagłówki i całą zawartość. Możesz także
530 użyć kontrolera frontowego aby zwrócił zawartość za pomocą metody
531 <code>returnResponse()</code>, a potem zrenderować odpowiedź używając
532 twojej własnej logiki. Przyszłe wersje kontrolera frontowego mogą
533 forsować użycie obiektu odpowiedzi przez wyświetlenie danych
534 wyjściowych.
535 </para>
537 <para>
538 Jest wiele dodatkowych funkcjonalności, które rozszerzają istniejące
539 API i są one opisane w dokumentacji.
540 </para>
542 <para>
543 Główne zmiany, na które musisz uważać, nastąpiły przy tworzeniu klas
544 pochodnych komponentów. Te zmiany to:
545 </para>
547 <itemizedlist>
548 <listitem>
549 <para>
550 <code>Zend_Controller_Front::dispatch()</code> domyślnie
551 łapie wyjątki w obiekcie odpowiedzi i nie renderuje ich
552 aby zapobiec wyświetlaniu ważnych informacji systemowych.
553 Możesz zmienić to zachowanie na kilka sposobów:
554 </para>
556 <itemizedlist>
557 <listitem>
558 <para>
559 Ustaw <code>throwExceptions()</code> w kontrolerze
560 frontowym:
561 </para>
562 <programlisting role="php"><![CDATA[
563 $front->throwExceptions(true);
564 ]]>
565 </programlisting>
566 </listitem>
568 <listitem>
569 <para>
570 Ustaw <code>renderExceptions()</code> w obiekcie
571 odpowiedzi:
572 </para>
573 <programlisting role="php"><![CDATA[
574 $response->renderExceptions(true);
575 $front->setResponse($response);
576 $front->dispatch();
578 // lub:
579 $front->returnResponse(true);
580 $response = $front->dispatch();
581 $response->renderExceptions(true);
582 echo $response;
583 ]]>
584 </programlisting>
585 </listitem>
586 </itemizedlist>
587 </listitem>
589 <listitem><para>
590 <code>Zend_Controller_Dispatcher_Interface::dispatch()</code>
591 zamiast tokena dispatchera przyjmuje i zwraca teraz
592 obiekt <xref linkend="zend.controller.request" />.
593 </para></listitem>
595 <listitem><para>
596 <code>Zend_Controller_Router_Interface::route()</code>
597 przyjmuje i zwraca obiekt <xref linkend="zend.controller.request" />
598 zamiast tokena dispatchera.
599 </para></listitem>
601 <listitem>
602 <para>Zmiany w <code>Zend_Controller_Action</code> to:</para>
604 <itemizedlist>
605 <listitem><para>
606 Kontruktor teraz przyjmuje dokładnie trzy argumenty,
607 <code>Zend_Controller_Request_Abstract $request</code>,
608 <code>Zend_Controller_Response_Abstract $response</code>,
609 oraz <code>array $params (opcjonalny)</code>.
610 <code>Zend_Controller_Action::__construct()</code> używa
611 ich aby ustawić żądanie, odpowiedź, i właściwości
612 invokeArgs obiektu i jeśli nadpisujesz konstruktor,
613 powinieneś je także ustawić. Lepiej jednak użyj
614 metody <code>init()</code> aby skonfigurować instancję,
615 ponieważ ta metoda jest wywoływana jako ostatnia akcja
616 konstruktora.
617 </para></listitem>
619 <listitem><para>
620 Metoda <code>run()</code> nie jest już zdefiniowana jako finalna,
621 ale nie jest też już używana przez kontroler frontowy;
622 Jej jedynym celem jest użycie klasy jako kontrolera strony.
623 Przyjmuje ona teraz dwa opcjonalne argumenty,
624 <code>Zend_Controller_Request_Abstract $request</code>
625 oraz <code>Zend_Controller_Response_Abstract $response</code>.
626 </para></listitem>
628 <listitem><para>
629 Akcja <code>indexAction()</code> nie musi być już
630 zdefiniowana, ale jest zalecana jako domyślna akcja.
631 To pozwala routerowi RewriteRouter oraz kontrolerom akcji
632 na określenie innych domyślnych metod akcji.
633 </para></listitem>
635 <listitem><para>
636 Metoda <code>__call()</code> powinna być nadpisana aby
637 obsłużyć automatycznie niezdefiniowane akcje.
638 </para></listitem>
640 <listitem><para>
641 Metoda <code>_redirect()</code> przyjmuje teraz opcjonalny
642 drugi argument, kod HTTP, który ma być zwrócony z
643 przekierowaniem oraz opcjonalny trzeci argument,
644 <code>$prependBase</code>, który może zdecydować czy
645 bazowy adres URL zarejestrowany w obiekcie żądania ma być
646 dodany do adresu URL.
647 </para></listitem>
649 <listitem>
650 <para>
651 Właściwość <code>_action</code> nie jest już
652 zdefiniowana. Ta właściwość była obiektem
653 <code>Zend_Controller_Dispatcher_Token</code>, który
654 nie istnieje już w aktualnej wersji. Jedynym
655 zastosowaniem tokena było przechowanie informacji o
656 zażądanym kontrolerze, akcji i parametrach URL. Te
657 informacje są teraz dostępne w obiekcie żądania w
658 taki sposób:
659 </para>
661 <programlisting role="php"><![CDATA[
662 // Pobierz nazwę kontrolera z żądania
663 // Dotychczas dostęp do niej był za pomocą: $this->_action->getControllerName().
664 // Poniższy przykład używa metody getRequest(), ale możesz także bezpośrednio
665 // użyć właściwości $_request; użycie getRequest() jest zalecane ponieważ klasa
666 // rodzica może nadpisać dostęp do obiektu żądania.
667 $controller = $this->getRequest()->getControllerName();
669 // Pobierz nazwę akcji z żądania
670 // Dotychczas dostęp do niej był za pomocą: $this->_action->getActionName().
671 $action = $this->getRequest()->getActionName();
673 // Pobierz parametry z żądania
674 // To się nie zmieniło; metody _getParams() oraz _getParam() teraz w prosty
675 // sposób wskazują na obiekt żądania.
676 $params = $this->_getParams();
677 $foo = $this->_getParam('foo', 'default'); // pobierz parametr 'foo', używając
678 // wartości 'default' jako domyślnej
679 ]]>
680 </programlisting>
681 </listitem>
683 <listitem>
684 <para>
685 Metoda <code>noRouteAction()</code> została usunięta.
686 Aby w poprawny sposób obsługiwać nieistniejące
687 metody akcji powinieneś przekierować je do domyślnej
688 akcji używając metody <code>__call()</code>:
689 </para>
691 <programlisting role="php"><![CDATA[
692 public function __call($method, $args)
693 {
694 // Jeśli została zażądania nieistniejąca metoda 'Action', żądanie zostanie
695 // przekazane do domyślnej metody akcji:
696 if ('Action' == substr($method, -6)) {
697 return $this->defaultAction();
698 }
700 throw new Zend_Controller_Exception('Nieprawdiłowa metoda');
701 }
702 ]]>
703 </programlisting>
704 </listitem>
705 </itemizedlist>
706 </listitem>
708 <listitem><para>
709 Akcja <code>Zend_Controller_RewriteRouter::setRewriteBase()</code>
710 została usunięta. W zamian użyj
711 <code>Zend_Controller_Front::setBaseUrl()</code>
712 (lub Zend_Controller_Request_Http::setBaseUrl(), jeśli używasz
713 tej klasy).
714 </para></listitem>
716 <listitem><para>
717 Interfejs <code>Zend_Controller_Plugin_Interface</code> został
718 zamieniony na <code>Zend_Controller_Plugin_Abstract</code>.
719 Wszystkie metody przyjmują i zwracają obiekt
720 <xref linkend="zend.controller.request" />
721 zamiast tokena dispatchera.
722 </para></listitem>
723 </itemizedlist>
724 </sect2>
725 </sect1>