Jak zauważyłem, w PHP 5.2.0 wprowadzono pewną zmianę, kilka elementów mojego frameworka przestało działać, lub działało wadliwie. "Dziwne" gubienie tablic przez __set() odkryłem zupełnie przez przypadek, podczas pracy nad frameworkiem zaraz po updacie serwera z silnika PHP 5.1.1 na 5.2.0. Problem jest opisany w tym topicku:

http://forum.php.pl/Tablice-w-php-520-t57734.html Zaraz po opisaniu problemu zacząłem robic wiele testów związanych z tą sprawą... rzeczywiście, __set() nie przyjmuje takich działań: $oObject->element[], gdzie atrybut "element" został wczesniej zadeklarowany jako tablica. Przypadek paradoksalny. Pozwoliłem napisać sobię dwustronnicowy "wywód" na ten temat, zacytuję go:

Dziś odkryłem swój błąd, który popełniłem przy tworzeniu tablic. Pokażę to na poniższym przykładzie:

PLAIN TEXT PHP:

1. Czytaj dalej tutaj (rozwija treść wpisu)
   Czytaj dalej na blogu autora...

   

   Zwiń
   Czytaj na blogu autora...

Pisząc frameworka pewnie wielu z nas zastanawiało się jak będą ładowane klasy gdy nie będziemy ich wymagać funckcją require(). Programiści Zend'a w swoim dziele nie dali nam tak zacnej możliwiości... wszystko ładujemy ręcznie, przynajmniej tak zauwazyłem ze wstępnych oględzin kodu i przykładów zastosowania. Z pomocą przychodzi nam funkcja __autoload(). Funkcja ta wyłapuje wszystkie próby dokonania instacji klas, interfejsów poprzez deklarację słowem kluczowym „new” bądź z poziomu statycznego.

Przykładowym kodem może być:

PLAIN TEXT PHP:

1. function __autoload($sClassName)
2. {
3. echo 'Loading class: ' . $sClassName . '... ';
4. }

Wówczas wyłapiemy wszystkie próby załadowania jakiejkolwiek klasy i interfejsów z któryych kożystają oarz klas „rodziców”. Naprawdę super sprawa. Najprostrzym sposobem ładowania klas jest umieszczanie ich w danym folderze i nazywanie plików tak samo, jak klasy w nich zawarte, np klasa Router będzie w pliku Router.Class.php w folderze /Classes/ :

PLAIN TEXT PHP:

1. function __autoload($sClassName)
2. {
3. require_once('./Classes/' . $sClassName . '.Class.php');
4. }

W powyższym przykładzie pliki klas sa ładowane bezpośrednio przed stworzeniem ich instancji. Ale co jak we własnym frameworku pliki klas nie są pokładane? Przykładowo: w folderze klas są posegregowane w inne foldery. Jak wówczas framework ma „zgadnąć” o jaką ścieżkę nam chodzi. Z pomoca przychodzi nam mapowanie folderu, czyli przegląd plików. Tablica jest tworzona w konstruktorze klasy głównej frameworka o wzorze 'Plik.Class.php' => './Sciezka/Plik.Class.php'. Funkcja __autoload() sformatuje sobie nazwę pliku, po czym poszuka jego ścieżki podając klucz tablicy... „szprytne” co nie?

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

To, co uważałem za istny przypadek w moim kodzie PHP, okazało się superkrytycznym bugiem w silniku PHP oznaczonym jako cricital bug w bugtrack. Otóż… destruktory nie mają dostępu do systemu plikow przy niszczeniu instancji klasy.

Przeglądając bugtrack natknąłem na 2 rzeczy:

http://bugs.php.net/bug.php?id=32412 - bug z php4 http://bugs.php.net/bug.php?id=30267 - bug z php 5.0.1

Naprawdę interesująca rzecz… założyłem topick wspomniany we wcześniejszej notce

Następną rzeczą o której chciałem wspomnieć to kolejna notka na moim blogu konkursowym “uczeń z klasą”. Dotyczy ona drugiej warstwy MVC którą opisuje: widok. Pozwole ją zacytować:

W poprzednim rozdziale omówiłem zasadę działania modelu, był on odseparowany od reszty warstw MVC. Z widokiem jest całkiem na odwrót… jest on uzależniony od kontrolera, który mówi, jakie dane przekazać widokowi, aby ten je wyświetlił. Niektóre z nich nie są mu w ogóle potrzebne. Klasę widoku możecie pooglądać, klikając jeden z zestawu linków, który znajduje się w repozytorium w notce z dnia 11 listopada. Przejdźmy do rzeczy:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Dziś miałem pracowity dzień w internecie... Byłem zmuszony zadać pytanie dotyczące na forum.php.pl w dziale PHP Pro o dostępie destruktora do funkcji unset(). Temat powiem bardzo interesujący... byc może napisze o tym artykuł, póki co odsyłam tutaj: http://forum.php.pl/Dostep-destroktora-do-unset-t56912.html Drugą rzeczą która miałem obowiązek wykonać to napisać notkę na moim blogu konkursowym, gdzie realizuje projekt mojego frameworka, [...]

Dziś dowiedziałem się że mam startować w konkursie "uczeń z klasą", projekt ma polegać na pisaniu bloga o tym, co robię w życiu najlepiej. Wybrałem tematykę programowania frameworka. Konkurs jest o tyle ciekawy, że tematykę projektu zakładam sobię sam i (co najlepsze) sam sobie rozkładam harmonogram działań. Budowę frameworka naciągnąłem od teraz do czerwca, wraz [...]

Frameworka w zasadzie skończyłem miesiąc temu, teraz wystarczy go przetestować, wyeliminować błędy i napisac kilka potrzebnych mi klas i bibliotek. Tym, którzy piszą frameworki zalecam przetestowanie go na jakimś większym projektem, gdyż wszystkie błędy wyjdą w przeciągu dwóch tygodni. Ja podjąłem się stworzenia portalu internetowego, który zakłada trzymać dziłay informacyjne, pocztę, wysukiwarkę (google api + [...]

Zend od jakiegoś czasu rozwija z powodzeniem swój framework. Szturmuje on rynek dzięki wsparciu firmy i dobrej dokumentacji. Zastanawia mnie jednak, dlaczego inni zaczęli kopiować to co w ZF jest. Rozumiem konwencję nazewniczą, ok - to może komuś się podobać, rozumiem strukturę katalogów, może ktoś uzna ją za logiczną.. Nie mniej nazewnictwo i struktura prawdę mówiąc nie różni się niczym od tego co było standardem w PEAR.

Co więcej, niektórzy po prostu przepisują spore fragmenty kodu, które są w ZF na swoje. Zapytam po co? Skoro jest coś podobnego w Zendzie to jaki sens jest w powielaniu praktycznie tego samego (Zend::loadClass, ZendRegistry, Zend_Router_Rewrite itp.)? Pomijam fakt, że Zend jest otwarty w tej chwili i na pomysły i na ludzi i zapytam, czy to ma jakiś sens?

Nie. Nie ma najmniejszego sensu ponieważ klony padną. ZF na 90% kiedyś wyjdzie i z powodzeniem wyprze wszystkie klony. Wyjście ZF to w dużej mierze kwestia prestiżu i marketingu a także być albo nie być dla PHP w świecie “rapid application development”, zgodnie z tym co głosi oficjalna strona http://framework.zend.com: Now, the world’s most popular web programming language gets even better with an easy to use framework for developing the next generation of web applications. . Bez tego Ruby oraz inne języki wspierane frameworkami po prostu zepchną PHP w kąt. Jak widać po statystykach PHP odrobiło spore straty rosnące niemal bez przerwy od zeszłego roku. Czy to tylko zasługa ZF? Wydaje mi się, że w dużej mierze tak.

Wnioskuję, że jeśli ktoś już zaczął robić framework wzorowany na zendowym to zna architekturę tego drugiego i nie tylko łatwiej ale i szybciej byłoby stworzyć to w oparciu o ZF. Pragnę nadmienić, że ZF ewoluuje, ostatnie propozycje zmian dotyczą między innymi warstwy MVC (dodatkowe informacje tu i tu).