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.
Najbardziej podstawowe użycie komponentów MVC nie zmieniło się; możesz nadal zrobić jak poniżej:
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 5.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ła 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 będziesz musiał uważać znajdziesz gdy będziesz tworzył klasy pochodne różnych kompnentów. Kluczowe zmiany to:
Zend_Controller_Front::dispatch()
domyślnie
łapie wyjątki w obiekcie odpowiedzi i nie renderuje ich
aby zapobiec wyświetleniu ważnych informacji systemowych.
Możesz nadpisać to 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()
teraz przyjmuje i zwraca obiekt Sekcja 5.1.2, „Obiekt żądania”
zamiast tokena dispatchera.
Zend_Controller_Router_Interface::route()
teraz przyjmuje i zwraca obiekt Sekcja 5.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.
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. Zamiast niej 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 5.1.2, „Obiekt żądania”
zamiast tokena dispatchera.