Autor wpisu: Splatch, dodany: 31.07.2006 23:19, tagi: php
Zgodnie z tym, co napisałem na forum php.pl zapraszam do ocen, bądź w temacie bądź tu, w zależności od sympatii. ;)
Zgodnie z tym, co napisałem na forum php.pl zapraszam do ocen, bądź w temacie bądź tu, w zależności od sympatii. ;)
Na początku odpowiedź na post, który napisał Zyx.
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.
Postami w tej kategorii chcę pokazać jak dalekie PHP jest od ideału. Mam nadzieję, że większość z tego co piszę kiedyś zostanie poprawiona, nie mniej póki co, są to grzechy ciężkie, które pokazują słabości PHP.
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
Zaprawdę, zaprawdę powiadam Wam drodzy czytelnicy Zend Framework do pełnej implementacji MVC ma jeszcze bardzo duży kwał drogi.
Dzisiejszego dnia postanowiłem poświęcić parę minut na bliższe spotkanie z ZF. Jak się szybko okazało nie był to czas spędzony bezowocnie. Utrwaliłem się w przekonaniu, że ZF to nie jest to czego szukam oraz znalazłem buga i to dość niewygodnego.. ;)
Dlaczego moje uprzedzenie do ZF nie zmalało a tylko wzrosło? Dlatego, że to co w sumie zobaczyłem odbiega od znanego mi (z innych frameworków) MVC. Może potraktuję Was tutaj odrobiną kodu:
PLAIN TEXT PHP:I oto się stało. Pierwszy raz użyłem przestrzeni nazw w PHP! Nie do wiary? A jednak. Nie było jakichkolwiek problemów z samą instalacją, ponieważ do pobrania jest paczka (pod Win ;)), która zachowuje się jak wszystkie inne pobrane z php.net. Przykłady podane na necie działają, więc nie pozostaje nic innego jak zabrać się za używanie przestrzeni nazw. :)
Oto listingi, które działają:
PLAIN TEXT PHP: