Dyzo rozmyślam o kanałach informacyjnych. Świetna sprawa, jeżeli wiem, że na mojej ulubionej stronie pojawiła sie nowa notka lub wpis, mogę zostawić sobie go do przeczytania na później wiedząc o tym, że jest. Mowię tutaj o kanałach RSS, XML i Atom. Specjalnie z tej okazji założyłem sobie na bloga OperaWidget. Teraz mój kanał RSS importowany jest do widżetu. Uruchomienie jest napradę proste. Teraz w pasku adresu macie nowy, niebieski przycisk, po jego uaktywnieniu na Operze możecie korzystać z widżeta mojego RSS.

Odnośnie samych kanałów RSS, w wigilijną noc zacząłem kodzić, gdyż będą stanowić część mojego frameworka. Stworzyłem trzy klasy, odpowiedzalne kolejno za kanały: RSS, Atom i XML. Powstała nowa notka na forum php.pl:

http://forum.php.pl/klasy-php5-Generator-kanalow-informacyjnych-Feeds-t59071.html

Może dział nie jest trafny co do mojego celu zamieszczenia tych klas, ale po części chodzi mi o ocenę. Ostatnio dużo myślałem nad obsługą kanałów informacyjnych w moim fameworku (ang. Feeds). Sprawa wygląda bardzo kontrowersyjnie, bowiem RSS nie cieszy się już taką dobrą opinią, jednak większość użytkowników używa właśnie tej wersji kanałów informacyjnych. Według ekspertów jego miejsce ma zastąpić kanał Atom, który stał się trendem i już rok temu liczba jego użytkowników znacznie wzrosła. Pomyślałem również o udostępnianiu naszych informacji w formie czystego arkusza XML.

Vfeed 0.1 - download

Powstały kolejne klasy:

Feed.Class.php – klasa abstrakcyjna, a zarazem rodzic wszystkich innych klas kanałów informacyjnych. FeedRSS.Class.php – kanał informacyjny w formie RSS FeedAtom.Class.php – kanał informacyjny w formie Atom FeedXML.Class.php – czysty arkusz Tagów XML, nie przedstawiany jako kanał, ale jako dostępne źródło informacji, zaliczyłem go jako kanał, gdyż można z niego pobierać informacje poprzez różne dostępne metody takie jak SimpleXML, czy SAX.

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

Zwiń
Czytaj na blogu autora...

Jeśli chcemy aby aplikacja korzystająca z podstawowych bibliotek Zend Framework w wersji 0.2.0 działała po aktualizacji frameworka do wersji 0.6.0 musimy wprowadzić kilka zmian. Wprawdzie w dokumentacji został opisany sposób migracji, ale tylko dla komponentów kontrolera. Poniżej kilka porad. Zmiana sposobu ustawienia ścieżki bazowej Dodanie drugiego parametru w wywołaniach konstruktora Zend_Filter_Input Zamiana konstruktorów __construct() w klasach kontrolerów na [...]

Ostatnio dużo myślałem nad tym, co jeszcze można dodać do mojego frameworka, bo jest bardzo duży, a do publikacji (03.01.2007) już niedługo. Przez moją myśl przeszło ściąganie plików… no tak. Teraz gdzie to ująć . Mam klasę odpowiedzialną za przechwycenie uploadowanych plików, zbieranie informacji o nich, kopiowanie. Może tam? Owszem.

Kwestia ściągnięcia plików jest bardzo prosta: do przeglądarki wysyłamy odpowiednie nagłówki oraz wczytujemy treść, która zostanie pobrana. Możemy podjąć dowolną nazwę pliku, chociaż oryginalny ma nazwę stałą. Zacząłem szukać źródeł, w których zastosowane jest pobieranie plików.

Szczególnie pomocnym skryptem okazał się FileSupply mojego kolegi Korneliusza Jarzębskiego (bardziej znany pod nickiem Bastion, autor słynnych klas takich jak Babel, Chameleon, ScoutGeo, FileMagic). Dlaczego ten skrypt? Przykładem jest funkcja ekspozycji pliku, na samej górze jest link, za pomocą którego bez problemu możemy pobrać plik. Zacząłem szperać w kodzie

Po zapoznaniu się ze sposobem pobierania (nagłówki umiałem wysłać już wcześniej), który opierał się na pobraniu zawartości plików „w kawałkach” postanowiłem zastosować to w nowej metodzie mojej klasy. Co oznacza tzw. Pobieranie „w kawałkach”? Często serwer mówi , że odczytywana treść wielkiego pliku przekroczyła dozwolony limit bajtów, haczykiem podsuniętym mi przez Bastion’a jest to, że pobieramy go w partiach: 64 * 1024 bajtów (64 kilo), po czym przerywamy odczyt i pętla działa dalej, od momentu w którym przerwaliśmy. Zapobiegnie to wyświetleniu błędów o dużym pliku .

Ok, czas na kod całej klasy, dodana została metoda download, która jest statyczna, można ją wykorzystywać bez uprzedniego wywoływania instancji klasy. W pierwszym parametrze podajemy ścieżkę do pliku, a w drugim (nieobowiązkowo) nazwa pliku, pod którą ma być on pobrany. Gdy drugi argument pozostanie pusty, nazwa pliku który zostanie wysłany jako nagłówek do ściągnięcia pozostanie taka sama jak oryginalny plik. Przed wywołaniem metody wysłania pliku, nie mogą zostać przesłane żadne nagłówki, po metodzie nie mogą być wykonywane żadne działania przez skrypt php.

Pełny kod obsługi plików w moim frameworku (omawiana została metoda Vfile::download() ): http://phpfi.com/187275

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

Zwiń
Czytaj na blogu autora...

Zend Framework osiągnął półmetek, dziś została wydana wersja 0.6. W tym roku to już ostatnie wydanie, kolejnych można będzie się spodziewać w styczniu (0.7), lutym (0.8) i w marcu (0.9 oraz 1.0RC). W wersji 0.6 dość mocno przebudowana została implementacja MVC, a w inkubatorze są już dostępne klasy do obsługi autoryzacji, uprawnień acl i obsługi [...]

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