Kolejne rozczarowanie Zend Framework
03 lis 2009
Nowy projekt (a właściwie dwa) mają zostać oparte o Zend Framework. Niby wszystko pięknie – no bo mamy „zajefajny” framework, który zrobi niemal wszystko (brakuje tylko faktu, że kawy nie parzy 
).
Chcąc mieć projekty pięknie od początku wykonane z użyciem Zend_Tool i Zend_Application generuje strukturę dokumentu. Przy czym, w ZF 1.8 zaleca się trzymanie wszystkich ustawień w konfiguracyjnym pliku INI (w celu odchudzenia klasy Boostrap).
Wracając do projektu – od razu zakładam panel administracyjny – tworzę osobny moduł.
Moduł ten będzie obsługiwał kontrolę dostępu i autentyfikację opartą o bazę danych. Żeby nie powielać kodu dziesiątki razy chcę stworzyć plugin kontrolera, który sprawdzi czy a. user jest zalogowany; b. ma dostęp do zasobu. I tu zonk.
W dokumentacji jest napisane, że w pliku INI można podać listę pluginów:
plugins: array of front controller plugin class names. The resource will instantiate each class (with no constructor arguments) and then register the instance with the front controller.
W przykładzie wygląda to tak:
resources.frontController.plugins.foo = "My_Plugin_Foo" resources.frontController.plugins.bar = "My_Plugin_Bar"
Niby wszystko jasne, tworzę dwie klasy dziedziczące po Zend_Controller_Plugin_Abstract… Teoretycznie powinienem mieć możliwość wywołania metody preDispatch(), która może sprawdzić czy użytkownik jest zalogowany i czy ma prawa do zasobu. Jeśli nie to, w zależności od sprawdzenia, albo przekierować go na formularz logowania, albo wyświetlić stronę z informacją o braku dostępu.
Teoretycznie – bo ten kod nie działa (błąd ładowania klasy, mimo że jest ona w include_path)!
Co więcej straciłem dziś 2 godziny na znalezienie „obejścia”. Obejście to nic innego jak stworzenie metody _initPlugins() w Bootstrap i po staremu dodanie pluginów do front kontrolera:
protected function _initPlugins()
{
$front = $this->bootstrap('frontController');
$front->registerPlugin(new My_Plugin_Foo());
}
Przy okazji przejrzałem dokładniej dokumentację ZF i takie oto wnioski przyszły mi do głowy:
- ZF to straszna kobyła, która sama w sobie nie trzyma standardów – można to samo wykonać na 3 różne sposoby (framework chyba powinien narzucać jeden standard!?)
- oficjalna dokumentacja jest nieaktualna
- API tez nieaktualne (Zend_Version) pokazuje numer 1.9.3
- jedyną pomocą są fora i bugtracker ZF
Do kolejnego razu! (oby można było powiedzieć coś in-plus…)
Komentarzy: 9
W dokumentacji „JEST NAPISANE” a nie w dokumentacji pisze
. Pozdrawiam. Bede wracal po wiecej wpisow o ZF.
felixd @ 04 lis 2009 0:23. #
a wystarczyło dodać namespace do autloader’a, w application.ini
autoloadernamespaces.my = „Myl”
i wszystko ładnie działa
milus @ 04 lis 2009 10:08. #
@felixd – dzieki juz poprawia, tekst byl pisany na szybko…
@milus – no wlasnie nie dzialalo z namespace’ami cos za bardzo :/
webit @ 04 lis 2009 10:49. #
hmm, aż sprawdziłem. wersja zf 1.8.1
mój config:
autoloadernamespaces.kamil = „Kamil”
includePaths.library = APPLICATION_PATH „/../library”
includePaths.models = APPLICATION_PATH „/models”
bootstrap.path = APPLICATION_PATH „/Bootstrap.php”
bootstrap.class = „Bootstrap”
resources.frontController.controllerDirectory = APPLICATION_PATH „/controllers”
resources.frontController.plugins.test = „Kamil_Controller_Plugin_Test”
no i plugin:
class Kamil_Controller_Plugin_Test extends Zend_Controller_Plugin_Abstract
{
public function preDispatch (Zend_Controller_Request_Abstract $request)
{
var_dump(„jestem tu i dziala”); die;
}
}
no i działa bez problemu
milus @ 04 lis 2009 12:53. #
Hm… Niestety ale przeważnie takie płytkie opinie padają z ust osób które nie rozumieją działania frameworka.
ZF @ 04 lis 2009 14:13. #
To ze nie „rozumie dzialania frameworka” to nie dokonca oznacza plytka opinie.
Od dawna sledze go i uzywam w razie potrzeby. Ale dopiero teraz widze jego niedociagniecia – braki w dokumentacji i api, nieaktualne przyklady, etc.
Oznacza to tez tyle ze sie troche zawiodlem na ZF.
webit @ 04 lis 2009 14:48. #
Niedociągnięcia ma każdy projekt. Uważam, że akurat dokumentacja jest bardzo dobra i można na jej bazie sporo się dowiedzieć i zrozumieć.
Żadna dokumentacja nie opisuje wszystkiego i na tyle dokładnie by zadowoliło każdego, a zwłaszcza w sytuacji kiedy osobie zainteresowanej się spieszy bo dany kod używa „w razie potrzeby”.
Rada, jeżeli mogę oczywiście, zdecyduj się na jeden framework i pisz w nim wszystko i non-stop. Wtedy dopiero będziesz mógł obiektywnie i kompetentnie pisać o jego wadach i niedociągnięciach. Na razie zwyczajnie frustrujesz się, że brakuje ci czasami wiedzy.
ZF dla mnie wymiata i czekam na kolejne releasy.
Btw. wg. roadmapy następny major ma mieć poprawioną dokumentacje. Może będzie lepiej, chociaż ja i tak uważam, że jest ok.
Pozdr
M
Mikee @ 04 lis 2009 16:51. #
Że tak się przypierdzielę, uwierzytelnianie, a nie „autentyfikację”, nie ma takiego słowa w języku polskim
A poważnie, to trzeba zacząć Cię subskrybować jako, że zaczynam przygody z ZF
Pozdrawiam Ciepło!
Andrzej @ 16 sty 2010 2:42. #
Zgodzę się za autorem wątku, dokumentacja Zenda jest do bani. Takiego „crapa” na oczy nie widziałem, na codzień korzystam z dokumentacji frameworków takich jak min. Spring, Struts2, Grails czy nawet zdarzyło się Ruby On Rails. Dobrą dokumentację naprawdę da się zrobić i tego o dokumentacji Zenda nie mogę powiedzieć.
wnuk @ 13 lis 2010 18:01. #