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.
Od czasu poprzednich zmian, najbardziej podstawowe użycie komponentów MVC pozostaje takie same:
require_once 'Zend/Controller/Front.php'; Zend_Controller_Front::run('/path/to/controllers');
Jakkolwiek, struktura katalogów została przebudowana, kilka komponentów usunięto, kilku innym zmieniono nazwy, a także kilka dodano. Zmiany to:
Klasa Zend_Controller_Router
została usunięta
na rzecz rewrite routera.
Nazwa klasy Zend_Controller_RewriteRouter
została zmieniona na Zend_Controller_Router_Rewrite
i awansowała ona na standardowy router dostarczany z frameworkiem;
Zend_Controller_Front
użyje go domyślnie, jeśli
żaden inny router nie zostanie ustawiony.
Nowa klasa trasy doa użycia z rewrite routerem została
przedstawiona, jest to
Zend_Controller_Router_Route_Module
; kryje
ona w sobie domyślną trasę używaną przez MVC i wspiera moduły
kontrolerów.
Nazwa klasy Zend_Controller_Router_StaticRoute
została zmieniona na
Zend_Controller_Router_Route_Static
.
Nazwa klasy Zend_Controller_Dispatcher
została
zmieniona na Zend_Controller_Dispatcher_Standard
.
Zmieniły się argumenty metody
Zend_Controller_Action::_forward()
. Sygnatura
wygląda teraz następująco:
final protected function _forward($action, $controller = null, $module = null, array $params = null);
Parametr $action
jest zawsze wymagany; jeśli
kontroler nie jest określony, to brana pod uwagę jest akcja
z obecnego kontrolera. Parametr $module
jest
zawsze ignorowany, o ile parametr $controller
nie jest określony. Ostatecznie każdy z parametrów w
tablicy $params
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.
Podstawowy sposób korzystania z komponentów MVC nie zmienił się; nadal możesz użyć poniższego kodu:
require_once 'Zend/Controller/Front.php'; Zend_Controller_Front::run('/path/to/controllers');
/* -- 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();
Jakkolwiek, po dodaniu obiektu Sekcja 7.1.5, „Obiekt odpowiedzi”, będziesz potrzebował zmienić ostatnią linię z tego przykładu na:
echo $ctrl->dispatch();
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 dispatch()
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
returnResponse()
, 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.
Jest wiele dodatkowych funkcjonalności, które rozszerzają istniejące API i są one opisane w dokumentacji.
Główne zmiany, na które musisz uważać, nastąpiły przy tworzeniu klas pochodnych komponentów. Te zmiany to:
Zend_Controller_Front::dispatch()
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:
Ustaw throwExceptions()
w kontrolerze
frontowym:
$front->throwExceptions(true);
Ustaw renderExceptions()
w obiekcie
odpowiedzi:
$response->renderExceptions(true); $front->setResponse($response); $front->dispatch(); // lub: $front->returnResponse(true); $response = $front->dispatch(); $response->renderExceptions(true); echo $response;
Zend_Controller_Dispatcher_Interface::dispatch()
zamiast tokena dispatchera przyjmuje i zwraca teraz
obiekt Sekcja 7.1.2, „Obiekt żądania”.
Zend_Controller_Router_Interface::route()
przyjmuje i zwraca obiekt Sekcja 7.1.2, „Obiekt żądania”
zamiast tokena dispatchera.
Zmiany w Zend_Controller_Action
to:
Kontruktor teraz przyjmuje dokładnie trzy argumenty,
Zend_Controller_Request_Abstract $request
,
Zend_Controller_Response_Abstract $response
,
oraz array $params (opcjonalny)
.
Zend_Controller_Action::__construct()
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 init()
aby skonfigurować instancję,
ponieważ ta metoda jest wywoływana jako ostatnia akcja
konstruktora.
Metoda run()
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,
Zend_Controller_Request_Abstract $request
oraz Zend_Controller_Response_Abstract $response
.
Akcja indexAction()
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.
Metoda __call()
powinna być nadpisana aby
obsłużyć automatycznie niezdefiniowane akcje.
Metoda _redirect()
przyjmuje teraz opcjonalny
drugi argument, kod HTTP, który ma być zwrócony z
przekierowaniem oraz opcjonalny trzeci argument,
$prependBase
, który może zdecydować czy
bazowy adres URL zarejestrowany w obiekcie żądania ma być
dodany do adresu URL.
Właściwość _action
nie jest już
zdefiniowana. Ta właściwość była obiektem
Zend_Controller_Dispatcher_Token
, 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:
// 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
Metoda noRouteAction()
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 __call()
:
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'); }
Akcja Zend_Controller_RewriteRouter::setRewriteBase()
została usunięta. W zamian użyj
Zend_Controller_Front::setBaseUrl()
(lub Zend_Controller_Request_Http::setBaseUrl(), jeśli używasz
tej klasy).
Interfejs Zend_Controller_Plugin_Interface
został
zamieniony na Zend_Controller_Plugin_Abstract
.
Wszystkie metody przyjmują i zwracają obiekt
Sekcja 7.1.2, „Obiekt żądania”
zamiast tokena dispatchera.