Aktualnie każdy, kto chce napisać nowe rozszerzenie do PHP, musi tylko znać język C, znać cel swej pracy oraz przeczytać rozdział 46 dokumentacji PHP zatytułowany “Zend API: Hacking the Core of PHP” i poświęcony właśnie tworzeniu modułów.

Zend API to nie wszystko. Moduły kompilowane nie są wyjściem super-uniwersalnym. Na co drugim serwerze nie ma opcji by dorzucić własne rozszerzenie. Wiele modułów z PECLa leży tam od lat, są one praktycznie nie rozwijane, także ich ilość niewiele może poświadczyć.

Projekt ten nie miał nigdy poprawiać po egoistycznie nastawionych twórcach baz danych oraz ich kreatywnym podejściu do implementacji standardu ANSI SQL, ale na plus należy zaznaczyć, że niektóre braki bibliotek klienckich są emulowane (np. podpinanie).

Nikt nie mówi, że PDO miałoby to poprawiać. Spójrz na JDBC, producenci baz samodzielnie dostarczają sterowników do połączeń i dbają o to by były zgodne z własną bazą oraz kolejnymi standardami w JDBC.

Ale głupotą byłoby negowanie go tylko dlatego, że w kwestiach wielkoskalowych ma braki, a Zend ostatnio stosuje dziwne podejście w kwestii doboru priorytetów i debugowania swego sztandarowego projektu.

Diabeł tkwi w szczegółach. Brak stosownych narzędzi i rozwiniętych rozwiązań technologicznych jest sporym problemem, który znacznie utrudnia tworzenie aplikacji.

XML i SAX
SAX jest świetnym standardem. Niestety, ustawianie gromady opcji dla parsera to jakaś porażka. Do tego domyślne zmienianie nazw tagów na wielkie litery.. jak by ktoś z tego korzystał.
SAX mógłby być świetnym rozwiązaniem, gdyby istniała klasa domyślnego parsera, która wymuszałaby implementacje tylko 2 metod – startElement i endElement. Niestety, jesteśmy skazani na to co, jest w PEAR, czyli kod pisany pod PHP 4.
Poza tym problem z SAXem w PHP jest taki, że jeśli ktoś chce korzystać z przestrzeni nazw w dokumencie, którego używa ma niewielkie szanse na to, że cokolwiek uda mu się ugrać, ponieważ parser nie przekazuje do handlera informacji o tym do jakiej przestrzeni nazw należy tag. Dla przykładu w Javie metoda startElement wygląda w następujący sposób:

void startElement(string uri, string localname, string qname, attributes atts)
a w PHP
void startElementImpl(resource parser, string localname, array atts)
czyli zupełnie tak samo jak by tych przestrzeni nie było. Jedyny sposób to wyciąganie prefiksu w nazwie (bo otrzymujemy np foo:bar) i sprawdzanie względem wcześniej zdefiniowanych poprzez xmlns.

DOM
Za implementację DOM Panom z Zenda należą się gratulacje, przede wszystkim dlatego, że w końcu jest to moduł doprowadzony do standardu, zgodnie z zaleceniami W3C. Nie będę już narzekał, że jest to DOM Level 2 a nie 3 co by nie było, że się za wiele czepiam ;). Świetnie, że DOM jest częścią Core PHP. Nie ma problemów z tym, czy DOM jest czy nie.

Testując DOM przed napisaniem tej noty trafiłem na błąd w obsłudze encji. Działają one w atrybutach ale nie w treści. Sprawa wygląda w ten sposób, że encje predefiniowane takie jak "e; są widoczne, zatem gdzie są moje? Uciekły bo się przestraszyły tagów.

SimpleXML
SimpleXML jest bramką pomiędzy DOM a SAX. Oferuje mniejszą funkcjonalność niż DOM, ale wymaga o wiele mniej pracy niż SAX. Po prostu, wczytujesz plik i działa. Niestety, nie jest tak różowo. W nim również znalazłem niedoróbkę. Nie jestem pewien czy nie została ona załatana, problem polegał na gubieniu atrybutu przy kolekcji. Denerwuje mnie również to, że nikną mi informacje o przestrzeni nazw. Jeśli przeglądam dokument iteracyjnie tracę informację o tym z jakiej przestrzeni jest element.

XSLT
Zbyt małe możliwości połączenia PHP i samego procesu transformacji. Do XSLT można przekazać tylko ciągi, zatem nie ma mowy o tym by wrzucić tablicę i na jej podstawie wykonać jakąś iterację. Niestety, nie te czasy. Plusem jest to, że można tworzyć funkcje do których parser potrafi się odwołać.. niestety są to albo funkcje albo statyczne odwołania do klas.

XSL-FO
XSL-FO to standard, który umożliwia przekształcenie dowolnego dokumentu XML do postaci binarnej takiej jak PDF. Niestety w PHP nie doczekaliśmy się jeszcze żadnej implementacji tego standardu, poza jedną klasą w PEAR, która usiłuje wykonać transformację przy użyciu Javy.

XSD
Z XSD w PHP jest zasadniczy problem. Nie istnieje. Można sprawdzić czy dokument jest zgodny ze schematem korzystając chociażby z DOMa, niestety nie ma żadnych narzędzi, które umożliwiają tworzenie klas ze schematu. Skala problemu znacznie się powiększa w chwili gdy korzystamy z WSDL, które pośrednio korzysta z XSD. Nie ma opcji, żeby stworzyć jakikolwiek typ złożony w PHP bez własnego kodu.

Rozbudowa o przykłady, być może wkrótce.

Zend

Zend jest firmą, która bez wątpienia ma największy wpływ na PHP. To Zend tworzy najważniejszy element PHP jakim jest Zend Engine.

To co mam do zarzucenia Zendowi to nieumiejętność wykorzystania swojej pozycji. Nie potrafi on wykorzystać swojej pozycji by ugrać coś na rzecz PHP. Być może dlatego, że jako firma jest zbyt mały by cokolwiek znaczyć. Od jakiegoś czasu Zend powoli produkuje papkę marketingową, którą wciska, że PHP jest enterprise podczas gdy samemu PHP jest do tego bardzo daleko. To, że został zmieniony silnik obsługujący obiekty, upodobniono składnię do Javy, wydano nową (piątą) wersję PHP nie czyni go enterprise.

Kiedy PHP stanie się językiem Enterprise? Kiedy dostarczy stosownych narzędzi i technologii. Niestety w chwili obecnej nie ma ani jednego ani drugiego. PHP jest wciąż językiem, który ma do tego aspiracje, ale nie ma możliwości (zupełnie tak jak Zend). Mam nadzieję, że z biegiem czasu i not z tej kategorii będę to udowadniał.

Z czym się do tej pory kojarzy PHP? Ze “stronkami” produkowanymi przez gimnazjalistów i licealistów. Nie odbiega to od faktów. Pytanie, dlaczego Zend zmierza w kierunku większych klientów? Odpowiedź jest oczywista, większe pieniądze. Tylko, za przeproszeniem, z czym do ludu?!

API, Technologie

Brak jakiegokolwiek API dla rozszerzeń. Parsery XML to nie tylko SAX, nie tylko DOM. Jeśli ktoś chce zaimplementować cały standard samodzielnie czy też go rozszerzać (choćby w samym PHP!) powinna być taka możliwość, niestety do tej pory jej nie ma i prawdopodobnie nie będzie, ponieważ PHP nie jest porządnie zaprojektowane.
Inną sprawą jest to, że nikt się tym nie zajmował i nie zajmuje. Błędne koło się zamyka, nikt nie myśli nad nowymi, porządnymi rozwiązaniami oraz technologiami opartymi o ten język, ponieważ PHP nie jest gotowe na taki krok. Wystarczy spojrzeć na Javę… Dla przykładu podam platformę J2EE. Sun publikuje pełną specyfikację i dostarcza przy okazji własny serwer, który w pełni tą specyfikację obsługuje. Nie przeszkadza to by równocześnie na rynku były obecne inne podmioty takie jak JBoss, BEA Web Logic i podstawa wszystkiego – Apache Foundation z Tomcat`em.

Społeczność i Zend Framework

Jak wiadomo społeczność PHP nie jest mała. Względem innych języków można powiedzieć, że jest ogromna. Nie mniej problemem społeczności jest jej podział i brak konsolidacji. Zend nie sprzyja tworzeniu społeczności wokół PHP. Przykładem może być Sun (który stoi na podobnej pozycji z Javą). Czym najłatwiej zgromadzić społeczność wokół własnej platformy? Oczywiście – projektami. Im więcej projektów tym więcej zaangażowanych ludzi i osób oraz firm nimi zainteresowanych. Tymczasem, co robi Zend? Prze ślepo w jednym kierunku, mianowicie w stronę własnego Frameworka, który od ideału jest daleki.

Jeden framework nie zdobędzie serc wszystkich programistów tym bardziej, że w PHP korzystanie z gotowych rozwiązań do w dalszym ciągu rzadkość. Zamiast wspierać chociażby konkurencyjne rozwiązania Zend nie robi nic, nawet nie kiwa palcem by przyciągnąć do siebie projekty. Przykładem może być Cake PHP, wokół którego zgromadziła się pokaźna grupka osób oraz Prado, które jest rozwiązaniem zgoła innym, działającym na zupełnie innych zasadach. Czyżby Zend nie wiedział, że w mnogości tkwi siła? Najwyraźniej tak, nie wspierając społeczności PHP wiele traci. To działa w obie strony, tak samo jak Zend może liczyć na takie samo wsparcie społeczności jako ono na jego.
PDO

PDO jest rozwiązaniem zdecydowanie spóźnionym i niedostatecznym jeśli myślimy o poważnych zastosowaniach. Podczas, gdy na rynku rozwijały się rozwiązania takie jak AdoDB i jego klony Zend nic nie robił w celu zatrzymania tego procesu. Doszło do sytuacji, kiedy PHP obsługuje wiele baz ale przez skrajnie różne rozszerzenia i funkcje. Jeszcze do niedawna było poprawiane rozszerzenie do obsługi PostgreSQL, by przypominało chociaż pozostałe. Do niedawna korzystanie chociażby z dwóch różnych baz danych wymuszało korzystanie z paskudnie napisanego AdoDB bądź implementowania tego samodzielnie.

PDO miało to zmienić, ale niestety nie do końca. PHP5 nie jest jeszcze zainstalowane na wielu serwerach, nie wspominając PHP 5.1 od którego PDO zostało wprowadzone. Wcześniejsze rozwiązania bazujące na “tradycyjnych” implementacjach używających funkcji natywnych nie mogą przeskoczyć nagle na PDO a nie mówiąc już o brakach w PDO.
Nie obsługuje ono wszystkich baz jakie do tej pory obsługiwało PHP oraz nie uwalnia definitywnie od różnic pomiędzy bazami. Pod tym względem PDO może przebić chociażby Creole nie mówiąc już o AdoDB, które obsługuje praktycznie wszystkie bazy, jakie do tej pory w PHP się pojawiły.

PHP6

Zbyt małe zmiany. Tak jak pisałem wcześniej, to jest powolna ewolucja, podczas gdy PHP jest potrzebna przemiana. Jeśli PHP ma z brzydkiego kaczątka kiedykolwiek stać się łabędziem to w tym tempie jeszcze lata ciężkiej i rzemieślniczej pracy przed nami, tym bardziej, że jesteśmy jeszcze w jajku, z którego się nie wykluliśmy.

Czy dodanie przestrzeni nazw diametralnie zmieni PHP? Zmieni zapewne ale nie na tyle by instytucje takie jak banki zainwestowały w PHP, bo jak wcześniej pisałem, nie jest to powód sam z siebie. Muszą się pojawić narzędzia, które wspomagają, uproszczają, porządkują prace nad bardzo dużymi aplikacjami. Ciągłe luki, niedoróbki, wydania, które są jednodniowe z racji krytycznych błędów bezpieczeństwa. To wszystko nie sprzyja budowaniu pozytywnego wizerunku samego PHP.