Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: Athlan, dodany: 30.11.2006 17:50, tagi: php

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...

Autor wpisu: Athlan, dodany: 19.11.2006 18:37, tagi: php, framework

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...

Autor wpisu: Athlan, dodany: 16.11.2006 17:34, tagi: php, framework

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...

Autor wpisu: Athlan, dodany: 14.11.2006 18:34, tagi: php

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, [...]

Autor wpisu: Athlan, dodany: 09.11.2006 17:39, tagi: framework

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 [...]

Autor wpisu: Athlan, dodany: 08.11.2006 12:48, tagi: framework

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 + [...]

Autor wpisu: Splatch, dodany: 03.10.2006 20:54, tagi: php, framework

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.

Statystyki php 2006-09 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).

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.