Some of posts from this blog has been moved to dywicki.pl. You will be automatically redirected to new blog if you would submit comment.
New posts are published on dywicki.pl, this blog contains old content and it is not continued.

Niektóre posty z tego bloga zostały przeniesione do dywicki.pl. Zostaniesz automatycznie przekierowany jeśli bedzięsz chciał dodać komentarz.
Nowe posty sa publikowane na dywicki.pl, ten blog zawiera stare treści i nie jest kontynuowany.

7 grzechów głównych PHP, XML

Filed under 7 grzechów,PHP,Wiadomości,XML by

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.

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.

4 responses so far

4 Responses to “7 grzechów głównych PHP, XML”

  1. Adi says:

    Jeszcze z tą obsługą XML’a w PHP nie jest tak źle, ale XSL-FO by się przydało :)

  2. Zyx says:

    Mała uwaga techniczna do odpowiedzi: moja ksywa to Zyx, natomiast “Zyxist” to nazwa strony WWW i mylenie tych dwóch pojęć może nieść ze sobą ciężkie skutki uboczne :).

    Natomiast ad. modułów/rozszerzeń: w takim razie co masz na myśli? Skoro moduły kompilowane nie, a tzw. “moduły niekompilowane” to zwykłe biblioteki napisane w PHP, które wystarczy ściągnąć, innej możliwości już nie ma. Być może masz na myśli rozwiązanie podobne do Javy – pakiety.

  3. splatch says:

    @Zyx Ksywka poprawiona. Tak, myślę o pakietach. O porządnych implementacjach mechanizmów, które ktoś (jak nie Zend to kto?) dokumentuje.
    Dla przykładu – SAX. Interfejsy, które powinny implementować handlery + klasy, które należy rozszeżać. To nie PEAR, to API + standardy.

  4. niskopoziomowy says:

    dla mnie php to jezyk dla dzieci, slawetne funkcje mail open exec, zwala na maksa

Leave a Reply