Głównymi zmianami, jakie pojawiły się w wersji 1.0.0RC1 jest dodanie i domyśle włączenie wtyczki ErrorHandler oraz pomocniczej klasy akcji ViewRenderer. Proszę przeczytaj uważnie dokumentację obu komponentów aby dowiedzieć się jak one działają i jakie efekty mogą one mieć w twoich aplikacjach.

Wtyczka ErrorHandler jest uruchamiana jako metoda postDispatch() 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 noErrorHandler:

<?php
$front->setParam('noErrorHandler', true);

Pomocnicza klasa akcji ViewRenderer 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 ViewRenderer będzie próbować renderować skrypt widoku oparty na nazwie akcji.

There are several strategies you can take to update your code. In the short term, you can globally disable the ViewRenderer in your front controller bootstrap prior to dispatching:

<?php
// Assuming $front is an instance of Zend_Controller_Front
$front->setParam('noViewRenderer', true);

However, this is not a good long term strategy, as it means most likely you'll be writing more code.

When you're ready to start using the ViewRenderer functionality, there are several things to look for in your controller code. First, look at your action methods (the methods ending in 'Action'), and determine what each is doing. If none of the following is happening, you'll need to make changes:

The easiest change is to disable auto rendering for that method:

$this->_helper->viewRenderer->setNoRender();

If you find that none of your action methods are rendering, forwarding, or redirecting, you will likely want to put the above line in your preDispatch() or init() methods:

public function preDispatch()
{
    // disable view script autorendering
    $this->_helper->viewRenderer->setNoRender()
    // .. do other things...
}

If you are calling render(), and you're using the Conventional Modular directory structure, you'll want to change your code to make use of autorendering:

If you're not using the conventional modular directory structure, there are a variety of methods for setting the view base path and script path specifications so that you can make use of the ViewRenderer. Please read the ViewRenderer documentation for information on these methods.

If you're using a view object from the registry, or customizing your view object, or using a different view implementation, you'll want to inject the ViewRenderer with this object. This can be done easily at any time.

There are many ways to modify the ViewRenderer, including setting a different view script to render, specifying replacements for all replaceable elements of a view script path (including the suffix), choosing a response named segment to utilize, and more. If you aren't using the conventional modular directory structure, you can even associate different path specifications with the ViewRenderer.

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

W wersji 0.9.3 pojawiają się klasy pomocnicze akcji. W związku z tym, poniższe metody zostały usunięte, z tego względu, że teraz są one zawarte w przekierowującej pomocniczej klasie akcji:

Przeczytaj dokumentację pomocniczych klas akcji aby uzyskać więcej informacji o tym jak można pobrać obiekty pomocnicze i jak nimi manipulować, oraz dokumentację przekierowującej pomocniczej klasy akcji w celu uzyskania informacji o ustawianiu opcji przekierowania (a także o innych metodach dla przekierowań).

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:

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 ???, 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: