Rosnąca popularność różnych frameworków, takich jak Ruby on Rails, sprawiła że wielu programistów PHP zadaje sobie pytanie, czy wciąż warto jeszcze rozwijać własne rozwiązania. W poszukiwaniu gotowych szkieletów aplikacji, sięgają najczęściej po Zend Framework. W tym artykule sprawdzimy, czy faktycznie oferuje on programiście PHP komfort pracy i zapewnia pisanym w oparciu o niego aplikacjom pewną przyszłość.
Oczywiście co do przyszłości nikt nie może
mieć pewności. Nic jednak nie wskazuje
na to, aby rozwój najpopularniejszych
frameworków miał stanąć w miejscu. Ma to duże
znaczenie, ponieważ kod aplikacji stworzonej przez
grupę obcych programistów ma tę wadę, iż trzeba
się go w końcu nauczyć na pamięć. Czas, który
programista potrzebuje na dokładne zapoznanie
się z silnikiem dowolnego frameworka, jest wedle
opinii wielu programistów zbliżony do czasu
potrzebnego na stworzenie analogicznej aplikacji,
tyle że własnoręcznie.
Korzyścią z tworzenia aplikacji samodzielnie jest
łatwa kontrola kodu oraz możliwość dokonywania
szybkich zmian. Z kolei aplikacja pisana zewnętrznie
jest mniej narażona na błędy bezpieczeństwa
i wielokrotnie lepiej przetestowana. Twórcy
frameworków zbyt często próbują jednak dogodzić
wszystkim gustom. W efekcie nie ma frameworka
bez nadmiernie rozbudowanej i zawiłej struktury.
Prace nad stworzeniem Zend Framework trwały
długo, bo ponad rok.
Dzięki temu udało się uzyskać bardzo wysokiej jakości kod wyjściowy. Widać
to gołym okiem, gdy przepuścić pliki ZF przez
inspektor wbudowany w edytor Zend Development
Environment. Nie bez znaczenia jest także fakt, że
framework jest dziełem firmy Zend Technologies,
odpowiedzialnej za rozwój PHP.
Co sprawiło, że firma Zend zdecydowała się
na rozpoczęcie prac nad własnym frameworkiem?
Prawdopodobnie jedną z przyczyn była chęć obalenia
mitu o PHP jako języku dla \”programistów\” (w
sensie dna programistycznego). Do programowania
w tym języku nie zabierają się na ogół zawodowi
programiści, którym w toku studiów wpaja się liczne
zasady inżynierii oprogramowania. Kod wynikowy
aplikacji jest z reguły fatalnej jakości, co czyni go
właściwie niemożliwym do dalszego rozwoju.
Ponadto PHP nie implementuje zaawansowanych
mechanizmów języka obiektowego, takich jak
np. przeciążanie operatorów (właściwość C++).
Wymagania
ZendFramework pracuje w oparciu o język
skryptowy PHP w wersji 5. Do pracy zapewne
potrzebna będzie również baza danych, choć nie
jest ona wymagana. Minimalne wymagania to
PHP 5.1.4 lub nowsze. Zalecana wersja PHP to
5.2.3 lub nowsza.
Do poprawnej pracy wymagany dostęp do modułu
{stala}mod_rewrite{/stala} serwera Apache. Jedynym celem
zastosowania {stala}mod_rewrite{/stala} jest przekierowanie
wszystkich żądań GET do jednego skryptu, wyłączając
z tego żądania do elementów statycznych.
Taki mechanizm można bez wysiłku zrealizować
na dowolnym serwerze http.
Dysponuje za to innym zestawem cech (dedykowanych
sieci funkcji i mechanizmów), które czynią
z niego narzędzie idealnie skrojone na potrzeby
tworzenia stron WWW i usług sieciowych.
Zend Framework ma być próbą odpowiedzi
Zend na rozwój konkurencji. Na myśl przychodzi
opisywany już na łamach \”Internet Makera\” Ruby
on Rails, framework oparty o język Ruby. Jego
największą bolączką jest fakt, że mimo wszystko
jest jeszcze wolniejszy od PHP, a jego instalacja
i konfiguracja na serwerach jest utrudniona. Lecz
sposób, w jaki narzuca programiście poprawny
styl kodowania i właściwą organizację, budzi
powszechny zachwyt.
Nie bez znaczenia pozostaje także czas, który
programista potrzebuje na wykonanie standardowych
aplikacji. O ile RoR sprawdza się tutaj
znakomicie, o tyle stworzenie w nim nieszablonowej,
rozbudowanej aplikacji staje się już bardzo
czasochłonne.
Możliwości i budowa Zend Framework
Ponad rok prac nad Zend Framework przyniósł
efekt w postaci ponad trzydziestu modułów o różnym
zastosowaniu. Framework oparto o wzorzec
projektowy Model Widok Kontroler (a konkretniej
Model 2 stosowany w sieci), którego potencjał
tkwi w podziale każdej produkcyjnej aplikacji na
trzy powiązane ze sobą części.
Model w aplikacji MVC odpowiada za
realizację logiki biznesowej, czyli za wszelkie
operacje związane z wymianą danych. Dotyczy to pobrania informacji z bazy danych i przetworzenia
tak uzyskanego wyniku do postaci,
którą można przekazać po obróbce graficznej do
użytkownika.
Dane przygotowane przez model aplikacji
trafiają do widoku, czyli części aplikacji, która
odpowiada za prezentację suchych danych otrzymanych
przez model w przyjaznej postaci – strony
WWW lub dokumentu XML.
Zadaniem kontrolera jest sterowanie żądaniami.
Oznacza to, że analizuje on dane, które trafiają
do aplikacji (adresu URL) i wybiera akcję (wchodzącą
w skład modelu), która pozwoli na poprawną
realizację zadania, np. wyświetlenie strony WWW
zawierającej treść odpowiedniego działu. Kontroler
jest zatem zwrotnicą, do której trafiają wszystkie
żądania realizacji usługi.
Oczywiście Zend Framework jest tylko podstawą
programistyczną, która pozwala na napisanie
zamierzonej aplikacji szybciej niż przy braku
gotowych modułów. Zaletą stosowania frameworków
jest praca w ramach (stąd jego nazwa), czyli
według narzuconych konwencji programistycznych
i reguł. Dla początkujących programistów może to
być wadą, ale praca według zbioru ustaleń pozwala
na uzyskanie dobrej jakości kodu, który można
następnie wielokrotnie wykorzystać.
ZF pracuje pod kontrolą PHP5, realizując
założenia aplikacji tworzonej w paradygmacie
zorientowanym obiektowo. Udostępniany jest na
licencji open source, co pozwala na stosowanie go
także w aplikacjach komercyjnych.
Dla kogo jest Zend Framework
Aby Zend Framework przyniósł programiście
korzyści, konieczne jest nie tylko poznanie
dostępnych modułów, ale także wiedza na temat
technik programistycznych wymaganych do
poprawnej realizacji aplikacji. Nie powinny być
nam obce wzorce projektowe i wszystkie dostępne
w PHP mechanizmy obiektowe. Bez tego realizacja
jakichkolwiek projektów będzie skutkowała
nieeleganckim, trudnym w zarządzaniu kodem
źródłowym. Nie wspominając już o utrudnionej
pracy grupowej.
Sposoby pracy z Zend Framework
Zend Framework pozwala na tworzenie
nieskomplikowanych skryptów realizujących proste
zadania. Za przykład niech posłużą gotowe aplikacje
dostarczane w zestawie z frameworkiem.
Do rozpoczęcia zadania wystarczy dołączenie
konkretnej biblioteki pakietu, bez konieczności
inicjalizacji całego silnika systemu. Ta zaleta czyni
z Zend Framework dobre narzędzie, które może
zostać dołączone do istniejącej aplikacji bez ryzyka
konfliktów.
Przykład dołączonej aplikacji do tworzenia dokumentów
PDF to demonstracja typowego skryptu,
realizującego szereg proceduralnych żądań. Nie
jest więc prawdą, że w ZF nie można stosować
innych paradygmatów niż obiektowy. Zdecydowanie
jednak aplikacja obsługująca wiele żądań musi
zostać napisana obiektowo.
Zend Framework może stanowić rozszerzenie
istniejącego systemu. Można również wykorzystać
go do utworzenia od zera nowej aplikacji
internetowej. Nie zapominajmy, że ZF będzie ciągle
w fazie rozwoju. Według zapewnień projektantów,
zmianie nie ulegną już żadne konwencje nazewnicze,
a interfejs istniejących klas także pozostanie
bez zmian. Ma to kluczowe znaczenie, gdyż decydując
się na rozwój własnych aplikacji, zależy nam
na uzyskaniu podstawy programistycznej, która
będzie rozwijana, ale bez wpływania na funkcjonowanie
dotychczasowych programów.
Architektura oprogramowania
Zanim podejmiemy decyzję o wyborze Zend
Framework jako podstawy programistycznej dla
naszych przyszłych projektów, warto poznać zasady,
którymi rządzi się zarówno sam framework, jak
i reguły, w oparciu o które pisane są później aplikacje.
Zalecana struktura aplikacji opartej o Zend
Framework prezentuje się następująco:
/application
/controllers
/models
/views
/filters
/helpers
/scripts
/library
/public
/images
/scripts
/styles
Możemy wyróżnić trzy główne katalogi, gdzie:
- Application zawiera komplet skryptów i szablonów
na potrzeby konkretnego projektu. - Library zawiera wszystkie skrypty, które
uznajemy za niezmienne dla każdego tworzonego
projektu. Do podstawy programistycznej
wchodzą zatem wszystkie klasy składające
się na Zend Framework, lecz nie tylko. Jeżeli
chcielibyśmy wykorzystać dodatkowe oprogramowanie,
np. system szablonów Smarty, to
właśnie tutaj należy umieścić jego pliki. Jeżeli
realizujemy wiele projektów, to z pewnością
zdecydujemy się na rozszerzanie możliwości
Zend Framework. Warto pamiętać, by robić to
z głową, tj. nie modyfikować istniejących klas,
a jedynie je rozszerzać. Nie wolno zapominać,
iż prace nad ZF ciągle trwają. Aby aktualizacja
bibliotek była możliwie bezproblemowa, należy
w pełni oddzielić dystrybucje od własnych
modyfikacji. Poprzednie wersje Zend Framework
wprowadzały zmiany w API, lecz ZF w wersji 1.0
gwarantuje, że kolejne odsłony, aż do wersji 2.0,
będą korzystały z tego samego API. - Public kryje w sobie wszystkie te pliki, które nie
powinny być interpretowane przez parser PHP.
Umieszczamy tu zatem elementy graficzne layoutu,
zdjęcia oraz skrypty JavaScript i style CSS.
Sama budowa Zend Framework jest prosta.
Do katalogu {stala}library/Zend{/stala} trafiają wszystkie
skrypty wchodzące w skład frameworka: jednemu
modułowi odpowiada katalog zawierający serię
klas. Główna klasa modułu znajduje się w katalogu
głównym, tj. library Zend.
Zend Framework kontra Ruby on Rails
Zarówno Ruby on Rails, jak i Zend Framework to frameworki, czyli oprogramowanie bazujące na określonym
języku programowania. W przypadku ZF jest to język PHP 5, natomiast Ruby on Rails pracuje
w oparciu o obiektowy język Ruby.
Popularność RoR sprawia, że wielu programistów PHP zaczyna odnajdywać w tym rozwiązaniu ciekawą
alternatywę dla PHP. Nauka RoR pociąga jednak za sobą konieczność zaznajomienia się z nowym językiem
programowania – mało popularnym do tej pory Ruby. Zupełnie inaczej jest w przypadku PHP, gdzie
to język pociąga za sobą gotowe rozwiązania.
Analogii między Zend Framework a Ruby on Rails można z pewnością znaleźć bardzo wiele. Które z tych
rozwiązań warto wybrać? Głównym powodem przemawiającym za RoR ma być szybkość tworzenia
nowych aplikacji. Gdy przychodzi jednak do tworzenia czegokolwiek, co nie zostało dokładnie przygotowane
przez programistów RoR, programowanie staje się dokładnie taką pracą, jak w przypadku PHP. Z tą
różnicą, że PHP wiele osób zna bardzo dobrze.
I tutaj wkracza Zend Framework, oferując dużą swobodę pracy, zestaw bibliotek i mechanizmów niezbędnych
do wdrażania paradygmatu MVC – a wszystko to w przyjaznym języku PHP.
Porównując kwestie wydajności obu rozwiązań, otrzymamy wynik przemawiający na korzyść PHP. RoR
wymusza na programiście korzystanie z mapowania relacyjno-obiektowego (ang. ORM), podczas gdy
Zend Framework nie implementuje mechanizmu typu ActiveRecord.
Silnik frameworka
Jak już wspomnieliśmy, Zend Framework jest
typowym frameworkiem MVC, co oznacza, że praca
w jego oparciu polega na tworzeniu trzech składowych.
Skrypty tworzymy, rozszerzając bazowe klasy
kontrolera i modelu. Dla każdej klasy kontrolera dodajemy
w widoku katalog o zgodnej nazwie. Każda
akcja odpowiada w tym katalogu jednemu plikowi
HTML o nazwie zgodnej z akcją. Co to oznacza?
Każda dynamiczna strona WWW budowana
jest w oparciu o żądania. Wprowadzając do okna
przeglądarki adres strony internetowej, oczekujemy,
że zwrócona zostanie strona główna. Gdy
jednak zażądamy adresu {stala}/artykuly/211.html{/stala},
oczekujemy że skrypt zwróci artykuł o identyfikatorze
w bazie równym 211. W Zend Framework
wszystkie żądania przekazywane są do jednego
skryptu. Skrypt taki określamy mianem bootstrapu,
inaczej sekcji rozruchowej.
Do zrealizowania boostrapu konieczne jest
przekazanie wszystkich żądań do pliku index.php.
By to zrobić, na serwerze umieszczany jest plik
{stala}.htaccess{/stala}, który przekierowuje wszystkie żądania
do naszego boostrapa. Plik ten napisany jest tak,
by pomijać arkusze stylów czy grafiki, które nie
powinny przechodzić przez interpreter PHP.
Przyjrzyjmy się następującemu adresowi URL:
{stala}http://www.mojastrona.pl/{/stala}
Zend Framework utworzy instancję klasy {stala}Index-Controller{/stala} ({stala}application/controllers/IndexController.php{/stala}) i uruchomi domyślną akcję {stala}indexAction(){/stala}.
W praktyce kod taki będzie wyglądał następująco:
class IndexController extends Zend_
Controller_Action {
function indexAction() {
echo \"Witaj Świecie!\";
}
}
W tym przykładzie nie skorzystaliśmy ani z bazy
danych, ani z jakiegokolwiek szablonu. Widać
jednak wyraźnie, że każde żądanie URL jest przenoszone
na konkretną klasę aplikacji.
Oto kolejny adres URL: {stala}http://www.mojastrona.pl/artykuly/{/stala}
Teraz utworzymy skrypt {stala}application/controllers/ArtykulyController.php{/stala} o następującej treści:
class ArtykulyController extends Zend_
Controller_Action {
function indexAction() {
echo \"To są artykuły!\";
}
}
Znów ZF będzie starał się znaleźć klasę
kontrolera, tym razem zwracając uwagę na klasę
zwierającą nazwę ukrytą w adresie URL oraz słowo
kluczowe Controller. Dla bardziej skomplikowanych
adresów, np.: {stala}http://www.mojastrona.pl/artykuly/dodaj.html{/stala}
ZF zwróci się do metody (funkcji) {stala}dodajAction(){/stala}
klasy {stala}ArtykulyController{/stala}.
Zadaniem kontrolera jest przechwytywanie
i obsługa żądań. Za pobieranie i przetwarzanie danych odpowiada model. Zend Framework obsługuje
bazy danych przy użyciu modułu Db_Table. To
podejście pozwala na modyfikowanie zawartości
bazy danych bez wymogu pisania zapytań SQL.
Jeżeli nasza aplikacja korzysta z tabeli artykuly,
wystarczy utworzyć następujący plik modelu
({stala}model/Artykuly.php{/stala}):
class Artykuly extends Zend_Db_Table {
protected $_name = ‚artykuly\';
}
W celu przygotowania listy wszystkich artykułów
dostępnych w serwisie wystarczy w kontrolerze
(będzie to {stala}ArtykulyController{/stala}) utworzyć obiekt
klasy Artykuly i jednym poleceniem udostępnić
wszystkie otrzymane dane widokowi:
$artykuly = new Artykuly();
$this->view->artykuly = $artykuly->fetchAll();
Widok jest niczym innym jak szablonem, w którym
określa się w jaki sposób dane mają zostać
wyświetlone. Najczęściej będzie to dokument
HTML zawierający fragmenty kodu PHP, odpowiedzialne
za faktyczne przekazanie dynamicznej treści
do szablonu. Nasz plik widoku dla kontrolera {stala}ArtykulyController{/stala}
({stala}http://www.mojastrona.pl/artykuly/{/stala})
powinien zostać zapisany jako {stala}views/scripts/artykuly/index.phtml{/stala} i może przyjąć następującą postać:
| Tytuł | Autor |
|---|---|
| escape($artykul->tytul);?> | escape($artykul->autor);?> |
W sieci znaleźć można wiele samouczków
pokazujących, jak projektować w oparciu o Zend
Framework – także po polsku.
Plany na przyszłość
Zend stawia przed projektem ZF jasne cele na
przyszłość. Ma to być ciągły rozwój wsparcia dla
usług sieciowych, obsługi technologii cyfrowej
identyfikacji tożsamości (np. OpenID), stworzenie
mechanizmów do obsługi formularzy zgodnie
z najlepszymi praktykami programistycznymi oraz
integracja z YAML (nietypowym językiem programowania
opartym na znacznikach; stosowanie go
pozwala na prezentację zawartości i zależności
występujących w pewnej grupie danych).
Usługi sieciowe
Feed – komponent pozwalający na generowanie
i odczyt kanałów RSS oraz Atom. Dostarcza mechanizmów
monitorujących odnośniki w kanałach,
pozwala na pobieranie kanałów z wielu źródeł,
a także zapewnia interfejs do publikacji kanałów.
Gdata – moduł do obsługi usług sieciowych
oferowanych przez Google. Dzięki niemu możliwa
jest wymiana danych (wysyłanie i odbiór) pomiędzy
takimi usługami jak Dokumenty Google,
Kalendarz, Blogger i CodeSearch.
Http_Client – odpowiada za nawiązywanie
zdalnych połączeń HTTP w celu odbioru danych,
wraz ze sprawdzaniem adresów URL, obsługą
ciasteczek oraz serwerów proxy.
Rest_Client – moduł klienta serwera usług
sieciowych REST. Dla żądania typu GET zwracana
jest odpowiedź POST.
Rest_Server – moduł serwera usług sieciowych
REST.
Service – moduł Zend_Service składa się z kilku
modułów, które odpowiadają za obsługę usług
sieciowych. Dzięki modułowi Service możemy
w bardzo uproszczony sposób wymieniać dane
z takimi serwisami jak Flickr czy del.icio.us.
XmlRpc – odpowiada za wymianę danych
pomiędzy usługami sieciowymi w standardzie
XML-RPC.
I18N i L10N
Moduły z tego działu odpowiedzialne są za
obsługę wielojęzyczności (I18N) i lokalizacji (L10N).
Wielojęzyczność oznacza wsparcie dla tłumaczeń,
natomiast lokalizacja uwzględnia takie kwestie jak
różnica w prezentacji dat (01-02-2008 i 02-01-
-2008), jednostek miar (cal i centymetr) i walut
($1.5 i 3,6 zł).
Currency – moduł odpowiedzialny za prawidłową
obsługę walut na witrynach, gdzie istnieje
więcej niż jedna jednostka monetarna.
Date – moduł odpowiedzialny za obsługę
poprawnego formatowania dat. Oferuje możliwość
obliczenia czasu wschodu i zachodu słońca w dowolnym
mieście.
Locale – moduł zbiorczo realizujący kwestie
związane z lokalizacją aplikacji internetowych.
Brane pod uwagę są takie kwestie jak lokalizacja
liczb, dat, czasów lokalnych, miar i wag.
Measure – moduł odpowiedzialny za dokonywanie
konwersji pomiędzy jednostkami miar i wag.
Measure pozwala na dodawanie, odejmowanie
oraz porównywanie miar i wag zapisanych w różnych
systemach.
Translate – dostarcza przejrzysty interfejs do
obsługi tłumaczeń.
Sesja i użytkownik
Auth – moduł odpowiedzialny za sprawdzanie
tożsamości użytkowników. Bazuje na module
Session, chociaż nie jest z nim ściśle związany.
Acl – zapewnia interfejs do obsługi praw
dostępu w aplikacjach, dzięki czemu możliwe jest
zrealizowanie zaawansowanego schematu kontroli
dostępu dla użytkowników.
Session – moduł odpowiedzialny za przechowywanie
danych sesji użytkownika. Obsługuje
przestrzenie nazw, co pozwala na rozszerzenie obsługi
sesji do realizacji bardziej złożonych aplikacji.
Moduł uwzględnia takie sytuacje jak przeterminowanie
sesji czy przywrócenie utraconego numeru
sesji.
Wydajność i bezpieczeństwo
Cache – caching to proces zapisywania danych
wyjściowych aplikacji w formie statycznej, w celu
przyspieszenia działania aplikacji. Ponieważ najkosztowniejszą
operacją wykonywaną przez każdy
skrypt jest dostęp do bazy danych, caching ogranicza
częstość tych odwołań poprzez zapis przetworzonych
rezultatów w formie plików. W ZF caching
może zostać realizowany w oparciu o standardowy
system plików, zapis w SQLite, memcache, APC
(rozszerzenie PHP) lub Zend Platform.
Filter – moduł odpowiedzialny za filtrowanie
zmiennych wejściowych w taki sposób, aby zapobiec
przynajmniej atakom SQL Injection. Moduł
Filter stosujemy wszędzie tam, gdzie użytkownik
wprowadza dane.
Filter_Input – wersja modułu Filter, która dobrze
radzi sobie z tablicami. Służy zatem głównie
do filtrowania danych przesyłanych metodami {stala}GET{/stala}
i {stala}POST{/stala}, widocznych w PHP jako asocjacyjne tablice
superglobalne (odpowiednio) {stala}$_GET{/stala} i {stala}$_POST{/stala}.
Memory – pozwala na przechowywanie
w trakcie wykonywania programu bardzo dużej
ilości danych. W normalnej sytuacji otrzymalibyśmy
informację o przeładowaniu bufora. Tutaj moduł ZF
dba o takie operowanie danymi, aby taka sytuacja
nie nastąpiła.
Validate – moduł odpowiedzialny za sprawdzanie
zmiennych pod kątem ich zgodności z oczekiwaną
wartością. W ten sposób sprawdzimy, czy
przesyłana zmienna jest liczbą całkowitą lub czy
jest poprawnym adresem e-mail.
Podsumowanie
Zend Framework to bardzo atrakcyjna propozycja
dla wszystkich programistów PHP, którzy
przez dłuższy czas szukali odpowiedniego silnika
dla swoich aplikacji. Choć Zend Framework nie
jest w pełni rozwiniętym projektem (brakuje mu
np. systemu szablonowego), to stanowi doskonały
wzór, jak tworzyć i utrzymywać kod pisany w PHP.
Trudno oceniać wydajność tworzonych w oparciu
o niego aplikacji. Niemniej jednak, paradygmat
MVC oparty o konstrukcje języka PHP5 gwarantuje
dużą przenośność i skalowalność aplikacji.
Firma Zend mocno stawia na rozwój swojego
flagowego frameworka, dzięki czemu na pewno
unikniemy takich kłopotów, jak samodzielne
łatanie dziur bezpieczeństwa czy rozwój funkcjonalności
samych bibliotek. Możliwości w zakresie
współpracy z zewnętrznymi programami (np.
wykorzystanie Smarty czy Savant do obsługi
szablonów) to kolejne argumenty przemawiające
za Zend Framework. Dlatego końcowa ocena jest
bardzo zadowalająca.
Przegląd modułów
Czy ZF to narzędzie dojrzałe? Nie dowiemy się
tego z prostych przykładów wprowadzających.
Dlatego sięgniemy po zawartość pakietu modułów
wchodzących w skład Zend Framework i przekonamy
się, co on tak naprawdę potrafi.
O prawdziwej sile frameworka stanowią
bowiem właśnie moduły, które dostarczają środowisko
programistyczne i przyspieszają budowę
złożonych aplikacji. Wiemy już, że ZF oparto
o MVC, że do komunikacji z bazą wykorzystujemy
klasę abstrakcyjną. Lecz co z realizacją większych
celów – obsługą AJAX-a, formatu PDF, algorytmami
pozwalającymi na szybszą realizację wyszukiwania
i wielojęzycznością? Zobaczmy, jakie moduły
wbudowano w ZF 1.0.3 i czy możemy spodziewać
się kolejnych.
Ze względu na znaczną liczbę modułów,
dokonamy ich luźnego podziału na sześć grup.
Wszystkie moduły składają się z głównej klasy,
poprzedzonej przedrostkiem Zend i zawsze zawierają
dodatkowe klasy odpowiedzialne za realizację
poszczególnych zadań. Więcej informacji można
znaleźć w szczegółowej dokumentacji dostępnej
(także do pobrania) pod adresem http://www.zendframework.com.
Szkielet
Controller – zadaniem kontrolera jest przekazanie
sterowania aplikacji do konkretnej akcji. Mechanizm
ten realizowany jest za pomocą omawianego
już bootstrapa. Kontroler odpowiada za wywołanie
klas modelu odpowiedzialnych za operacje i przygotowanie
danych do wyświetlenia przez widok.
Do wykonywania typowych operacji, takich jak
przygotowanie menu rozwijanego, można wykorzystać
pomocniki akcji (Action Helpers) lub rozszerzenia
kontrolera (Controller Plugins). Kontroler jest
głównym wykonawcą w aplikacji MVC.
View – Zend Framework nie ma własnego
systemu obsługi szablonów. Aktualna propozycja
przewiduje tworzenie widoku w oparciu o kod prezentacji
przeplatany z odwołaniami do obiektów
z danymi przekazywanymi przez kontroler. Możliwe
jest jednak zaimplementowanie innych rozwiązań,
takich jak Smarty czy Savant.
Db – abstrakcja dostępu do bazy danych,
pozwalająca na łatwe przejście z jednego systemu
bazodanowego na inny. Do aktualnie obsługiwanych
baz danych zaliczają się MySQL, PostgreSQL,
MsSQL, SQLite, Oracle, IBM DB2. Programowanie
w oparciu o moduł Db oznacza co prawda brak
konieczności pisania kompletnych zapytań SQL,
lecz większość operacji wykonywanych na bazie
danych i tak będzie wymagało określenia szczegółów
zapytania (nazwa tabeli, klauzula from, where,
order itd.). Interfejs systematyzuje więc współpracę
z bazą danych, lecz programista wciąż musi
dokładnie określić, o jakie zapytanie mu chodzi. To
rozwiązanie jest zatem zdecydowanie najszybsze,
lecz wymaga najwięcej uwagi.
Db_Table – to swojego rodzaju abstrakcja
abstrakcji klasy Db. Zadaniem Db_Table jest
pozwolenie programiście na bardzo łatwe operowanie
na tabelach. By odczytać wszystkie dane z konkretnej tabeli, wystarczy zadeklarować nazwę
tabeli w klasie rozszerzającej {stala}Zend_Db_Table{/stala}. Co
prawda {stala}Db_Table{/stala} nie jest modułem typu ORM (do
obsługi mapowania relacyjno-obiektowego), lecz
w określonym stopniu implementuje mechanizmy
zbliżone do ActiveRecord, znanego z Ruby on Rails.
Brak obsługi encji jest przedmiotem wielu dyskusji,
gdyż zbytnia automatyzacja zarządzania bazą
danych powoduje wzrost wymiany danych między
bazą a programem, co jest niekorzystne w przypadku
rozbudowanych aplikacji.
Config – moduł ten dostarcza interfejs do
obsługi plików konfiguracyjnych. Dzięki niemu
możemy stworzyć plik {stala}.ini{/stala}, który będzie skrywał
np. dane konfiguracyjne bazy danych. Config
zadba o odpowiednią wydajność, buforując odczyt.
Stopień zaawansowania plików konfiguracyjnych
może być dowolny.
Log – ten moduł odpowiada za generowanie
tzw. logów, które pełnią funkcję administracyjną.
Przechowywanie krótkich informacji o zmianach
i błędach w systemie jest sposobem na stworzenie
bezpiecznej aplikacji o wysokiej niezawodności.
Logi mogą być przechowywane zarówno w plikach,
jak i w bazie danych.
Mail – obsługuje rozsyłkę wiadomości e-mail
z załącznikami. Wspierający typy MIME i różnorodne
sposoby komunikacji z agentami rozsyłki.
Mime – moduł odpowiedzialny za obsługę
typów MIME.
Search_Lucene – moduł Search_Lucene to
próba przeniesienia projektu o tej samej nazwie
napisanego w języku Java. Moduł pozwala na realizację
zaawansowanego, inteligentnego systemu
wyszukiwawczego wśród pól typu full-text tabel
w bazach danych. Napisanie własnego rozwiązania
wyszukiwawczego jest złożone, a moduł Lucene
gwarantuje bardzo wydajne uzyskiwanie trafnych
wyników wyszukiwania.
Version – moduł pozwalający na porównanie
dwóch skryptów pod kątem naniesionych w nich
zmian.
Moduły pomocnicze
Console_GetOpt – umożliwia tworzenie konsolowych
aplikacji sterowanych z linii poleceń. Przydatne
do konstruowania szybkich w użyciu aplikacji
wspomagających pracę administratora witryny.
Loader – moduł odpowiedzialny za uruchomienie
kompletnego silnika Zend Framework.
Odpowiada za dynamiczne ładowanie plików, klas
i zasobów do aplikacji.
PDF – służy do generowania dokumentów PDF.
Bardzo proste API pozwala na szybkie przygotowanie
nawet rozbudowanych graficznie plików PDF.
Registry – pozwala na tworzenie i odczyt zmiennych,
które będą widoczne w obrębie całej aplikacji.
Do realizacji tego mechanizmu wykorzystano
wzorzec projektowy Singleton, który ogranicza ilość
instancji klasy Registry do jednej. Dzięki takiemu
zabiegowi możemy operować na naszym rejestrze
w dowolnej części aplikacji bez obawy o wymianę
danych między poszczególnymi obiektami. Registry
to dobra alternatywna dla zmiennych globalnych,
których używanie w rozbudowanej aplikacji może
przynieść niechciane efekty (np. dublowanie się
zmiennych, brak pełnej kontroli).
URi – pozwala na tworzenie, manipulowanie
oraz sprawdzanie poprawności adresów URL.
JSON – moduł przydatny do realizacji techniki
AJAX. Pozwala na zamianę struktur PHP na odpowiednik
dla języka JavaSciprt, tzw. notację JSON
(ang. JavaScript Object Notation).
