Spośród wszystkich popełnionych przeze mnie wpisów na temat Zend Framework, kilka w jakiś sposób nawiązywało do ajaxa. Nie opisałem jednak sposobu w jaki ZF pozwala obsługiwać requesty ajaxowe.

AjaxContext podobnie z resztą jak ContextSwitch, który jest jego bardziej ogólną wersją, umożliwia obsłużenie w jednej akcji różnych żądań i w zależności od kontekstu takiego żądania, zwraca dane w odpowiednim formacie. Typ żądania można rozpoznać po wartości zmiennej format, przesłanej w adresie. Zazwyczaj zmienna ta odpowiada typowi danych jaki chcemy zwrócić. Jedną z wielu zalet korzystania z AjaxContext jest to, że w razie wywołania akcji z parametrem format wskazującym na ajaxowy kontekst nie poprzez ajax (np bezpośrednie wpisanie adresu do przeglądarki), wówczas kontekst nie zostanie użyty, a do renderowania widoku użyty zostanie standardowy widok.

Skoro już przy widokach jesteśmy, to należy wiedzieć, że każdy kontekst posiada swój własny plik widoku z odpowiednim prefixem, który dodawany jest przed rozszerzeniem pliku. W przypadku AjaxContext jest to .ajax. Wówczas w katalogu scripts znajdą się dwa pliki widoku, jeden o nazwie np index.phtml i drugi index.ajax.phtml. Funkcjonalność AjaxContext nie jest dostępna od razu dla każdej akcji. Sami musimy wskazać, która akcja z niej korzysta. Najlepiej zrobić to w metodzie init klasy kontrolera.

public function init()
{
	$ajaxContext = $this->_helper->getHelper('AjaxContext');
	$ajaxContext->addActionContext('index', 'html')
				->initContext();
}

Teraz wykonując request ajaxowy, wystarczy, że w adresie podany zostanie parametr format o wartości html. Poniżej kod jQuery

$.ajax({
	url: "/index/index/format/html",
	type: "POST",
	data: "zmienna1=wartosc1&zmienna2=wartosc2",
	success: function(html) {
		$("#ajax-content").append(html);
	}
});

W ten oto prosty sposób można stworzyć dwa różne skrypty widoku dla jednej akcji, wyświetlane w zależności od tego, czy mamy do czynienia z ajaxem, czy nie. Co ciekawe, w przypadku requestu ajaxowego, automatycznie wyłączany jest layout.

To jeszcze nie wszystko. Zmienna przypisana do widoku jest widoczna zarówno w skrypcie “normalnym” jak i ajaxowym. Co więcej, można wykryć, czy mamy do czynienia z ajaxem i zmodyfikować zawartość niektórych zmiennych, dodać nowe lub usunąć już istniejące.

public function indexAction()
{
	$this->view->jakasZmienna = 'zawartosc zmiennej';
	if($this->_request->isXmlHttpRequest()) {
		$this->view->jakasZmienna = 'zawartosc tylko w ajax';
	}
}

Na pewno część z was zastanawia się do czego może się przydać taka funkcjonalność. Najlepszym przykładem będzie paginacja i sortowanie danych w tabeli. Kolumna, po której dane mają być sortowane oraz numer strony do wyświetlenia, przechodzą przez ten sam kod w tej samej akcji, dzięki czemu nie trzeba pisać dwóch identycznych skryptów. Ponadto jeśli okaże się, że z jakiegoś powodu nie działa javascript, strona po prostu się odświeży, poprawne wyświetlając dane.

Więcej informacji na temat AjaxContext możecie znaleźć w manualu. Polecam również zajrzeć do działu poświęconego ContextSwitch.

Przykładową aplikację znajdziecie w repozytorium.

Podczas pisania aplikacji zbudowanej z modułów, można natknąć się na kilka dosyć poważnych problemów, na rozwiązanie których traci się sporo czasu. Poniżej zebrałem najczęściej powtarzające się problemy związane z modułami i ich rozwiązanie.

1. Dodawanie modułów do aplikacji Moduły do aplikacji można dodać na dwa sposoby – ręcznie lub przy użyciu Zend_Tool. W każdym z przypadków należy zmodyfikować plik konfiguracyjny. Pierwszą zmianą jest dodanie informacji o tym, że będziemy korzystać z modułów:

   resources.modules = ""

   Następnie należy wskazać ścieżkę, w której moduły się znajdują:

   resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"

   Ważne jest, by linijka ta została dodana po ścieżce do kontrolerów domyślnych (controllerDirectory). Całość będzie wyglądała następująco:

   resources.modules = ""
   resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
   resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"

2. Zasoby w modułach. Dosyć często zachodzi potrzeba zastosowania konkretnego zasobu tylko w jednym module, np zmiana layoutu dla całego modułu:

   admin.resources.layout.layout = "layout_admin"

   W tym przypadku admin oznacza nazwę modułu, a layout_admin nazwę pliku z layoutem.
3. Bootstrap w modułach. W modułach można stosować pliki Bootstrap. Wystarczy, że w katalogu głównym aplikacji zostanie stworzony plik o nazwie Boostrap.php, a w nim klasa dziedzicząca po Zend_Application_Module_Bootstrap.

   class Admin_Bootstrap extends Zend_Application_Module_Bootstrap
   {
   }

   Jak widać nazwa klasa musi być poprzedzona prefiksem odpowiadającym nazwie modułu. Bootstrap modułu można wykorzystać do dodania specyficznych ustawień dla danego modułu, np inicjalizacja menu.
4. Ładowanie wszystkich modułów podczas inicjalizacji aplikacji. Jest to jeden z największych problemów podczas korzystania z modułów. Jeśli w pliku Bootstrap.php konkretnego modułu zostanie dodany np plik css, który znacząco modyfikuje wygląd strony, wówczas zostanie on wczytany za każdym razem, nawet jeśli nie znajdujemy się w tym module. By temu zaradzić trzeba trochę się nakombinować. Najpierw należy wyłączyć ładowanie modułów. W tym celu należy w głównym pliku Bootstrap dodać pustą metodę _initModules

   protected function _initModules()
   {
   }

   Następnie musimy stworzyć plugin, który załaduje aktualny moduł.

   class Batman_Controller_Plugin_ModuleLoader extends Zend_Controller_Plugin_Abstract
   {
   	public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
   	{
   		$module = $request->getModuleName();
   
   		// moduł domyślny można ominąć
   		if($module == 'default') {
   			return;
   		}
   
   		// ścieżka do pliku Bootstrap
   		$path = APPLICATION_PATH . '/modules/' . $module . '/Bootstrap.php';
   
   		// nazwa klasy Bootstrap
   		$class = ucfirst($module) . '_Bootstrap';
   
   		// inicjalizacja, załadowanie i utworzenia obiektu klasy Bootstrap modułu
   
   		$application = new Zend_Application(
   			APPLICATION_ENV,
   			APPLICATION_PATH . '/modules/' . $module . '/configs/module.ini'
   		);
   
   		Zend_Loader::loadFile('Bootstrap.php', dirname($path));
   		$bootstrap = new $class($application);
   		$bootstrap->bootstrap();
   	}
   }

   Nie można zapomnieć o wywołaniu tego plugina, np w głównym pliku bootstrap

   protected function _initPlugins()
   {
   	$this->bootstrap('frontController');
   	$front = $this->getResource('frontController');
   	$front->registerPlugin(new Batman_Controller_Plugin_ModuleLoader());
   }

   Ostatnią rzeczą jaka pozostała do zrobienia jest dodanie katalogu configs w folderze modułu, a w nim pliki module.ini. Nazwa pliku konfiguracyjnego jest oczywiście w pełni umowna i można zastosować dowolną. Odwołania do zasobów w pliku konfiguracyjnym tworzy się tak samo jak w punkcie 2 tej listy.

Początkowo Zend Framework był zbiorem bibliotek, z których miały posiadać spójny interfejs. Z czasem rozwinął się do pełnoprawnego frameworka, przez co niektóre z jego funkcjonalności pozostały w cieniu. Tak jest w przypadku Zend_Markup. Od razu muszę napisać, że nie pokażę żadnych magicznych sztuczek, ani specjalnych wrapperów. Wpisem tym chciałem jedynie zasygnalizować, że takie coś istnieje i

W dniu dzisiejszym pracowałem nad generowaniem plików PDF w swojej aplikacji. Wybrałem do tego celu Zend_Pdf dlatego że backend jest oparty na Zend Framework.

Współprace z tą biblioteką mogę ocenić na 4/6. Przyjemnie. Jednak brakuje w niej kilku kluczowych elementów jednym z nich jest możliwość zawijania długiego tekstu. W sposób natywny ZF nie ma zaimplementowanej takiej metody.

Poniżej przedstawiam prostą funkcję, która w szybki i sprawny sposób zawinie (przełamie) przekazany tekst po określonej długości znaków.

/**
* Zawin tekst po określonej długości znaków.
*
* @param Zend_Pdf_Page $page
* @param string $text
* @param int $x
* @param int $y
* @param int $width
* @param string $brake
* @param bool $cut
* @return void
*/
function drawTextWrap($page, $text, $x, $y, $width, $brake = "\n", $cut = true)
{
// przygotuj tekst
$text = wordwrap($text, $width, $brake, $cut);
$token = strtok($text, $brake);

$fontSize = $page->getStyle()->getFontSize();

// rysuje każdą linię tekstu niżej od poprzedniej
// o wysokośc (wielkość) czcionki
while (false !== $token)
{
$y -= $fontSize;

$page->drawText($token, $x, $y);

$token = strtok("\n");
};
}

Jeżeli ktoś pracował z Zend_Pdf to wytłumaczenie jak użyć w/w kawałek kodu jest zbyteczne. Pozdrawiam.

Zdarza się czasami, że projekt nad którym pracujemy wymaga połączenia z więcej niż z jedną bazą danych, niekoniecznie opartych o ten sam silnik bazodanowy. Zend Framework wyszedł na przeciw oczekiwaniom programistów i stworzył zasób multidb. Dzięki niemu, istnieje możliwość zdefiniowania wielu połączeń do różnych baz danych. W momencie, gdy zachodzi potrzeba skorzystania z innej niż podstawowa

Domyślne ustawienia Zend_Form powodują, iż błędy walidacji wyświetlają się bezpośrednio pod elementem, w którym wystąpił błąd. Czasami zachodzi potrzeba wyświetlenia wszystkich błędów nad formularzem (lub w innym miejscu). Rozwiązań tego problemu jest kilka. Dzisiaj zaprezentuję najszybsze. Rozwiązanie to polega na stworzeniu helpera widoku, który przechwyci i wyświetli komunikaty błędów. W

Jeśli kiedykolwiek zdarzyło się wam pisać mechanizm Top 10, na pewno natknęliście na masę problemów – zbieranie i przetwarzanie danych, obciążenie serwisu, poprawność zebranych danych. Im większy serwis, tym więcej problemów. Dzisiaj pokażę jak w bardzo prosty sposób można stworzyć mechanizm Top 10 w oparciu o Google Analytics i Zend Framework. W teorii wygląda to tak: przy pomocy API