Witam,
przedstawiam do oceny parser HTML mojego autorstwa.

Plik do pobrania:
http://www.filedropper.com/htmlparserclassphp

Opis:
Zasada działania jest prosta, wystarczy zaincludować plik z klasą, która znajduje się w powyższym pliku. Następnie utworzyć nowy obiekt, np.

[PHP] pobierz, plaintext 
$parser = new HTMLparser();
[PHP] pobierz, plaintext 

Dostępne są 3 metody pobierania HTML, który będziemy parsować:
- z pliku

[PHP] pobierz, plaintext 
$parser->parseFile($dir);
[PHP] pobierz, plaintext 

- ze stringa

[PHP] pobierz, plaintext 
$parser->parseString($string);
[PHP] pobierz, plaintext 

- z URL

[PHP] pobierz, plaintext 
$parser->parseUrl($url);
[PHP] pobierz, plaintext 

Następnie wywołanie parsera:

[PHP] pobierz, plaintext 
$resource = $parser->find('div');
[PHP] pobierz, plaintext 

Jako wynik zmienna $resource będzie przechowywać tablicę obiektów DIV-ów znalezionych w parsowanym źródle, bądź jeden obiekt, jeśli w metodzie find jako drugi argument podamy liczbę (wtedy zwróci n-ty DIV z parsowanego źródła).

Odczyt informacji:
Odczyt jest bardzo prosty, każdy wynik zawiera obiekty text oraz html, ponadto jeśli DIV posiada atrybuty, np. class bądź id zostaną one zwrócone również w postaci obiektów. Przykład:

[PHP] pobierz, plaintext 
foreach ($resource as $div) {
  echo $div->text;
  echo $div->html;
  echo $div->class;
  // itd.
}
[PHP] pobierz, plaintext 

To tak po krótce tytułem wstępu. Jednak parser wymaga optymalizacji, ponieważ czas parsowania średniej wielkości źródła jest dosyć długi. Proszę o oceny, a także o wskazanie dalszej drogi rozwoju owego parsera (zastanawiałem się jeszcze nad wyszukiwaniem elementów HTML np. po class, bądź po ID, jednak w tym momencie nie mam jeszcze pomysłu jak to zrealizować, bo już teraz parser w obecnej formie jest dość "ciężki"). Pozdrawiam i dzięki za ewentualne sugestie.

EDIT:
Zapomniałem dodać, możemy również szukać dzieci naszych wynikowych obiektów, np.

[PHP] pobierz, plaintext 
foreach ($resource as $div) {
  echo $div->find('a', 0)->href;
}
[PHP] pobierz, plaintext 

Możliwość zagnieżdżania jest nieograniczona.

Ja mam tylko jedno pytanie. Czemu miałbym używać Twojej, jak to sam określiłeś - zasobożernego parsera (zresztą nie dziwię się skoro najróżniejszych preg'ów w kodzie jak mrówek), zamiast powszechnie używanej i dużo bardziej rozbudowanej klasy DOMDocument?

Tzn. jest to dopiero wczesna wersja, nie zachęcam nikogo do użytkowania, a proszę jedynie o wykazanie błędów, ew. drogi rozbudowy / rozwoju. Sam parser powstał na mój własny użytek, nie mam zamiaru go nigdzie udostępniać (póki co), jakkolwiek jeśli ktoś jednak zechce skorzystać, to proszę bardzo, nie mam nic przeciwko. Ani nie pobieram opłat, ani nie zbieram dotacji, także wolny wybór użytkownika. A temat się tyczy jedynie oceny.

Na pierwszy rzut oka:

1. Brak modyfikatorów dostępu przy metodach
2. Dwie klasy w jednym pliku (tak nie powinno się pisać)
3. Mało komentarzy w kodzie oraz mało poprawne tagi phpdoc (@param, a nie @params)
4. Projektując klasę nie powinno się już raczej używać kończącego tagu php ?>
5. Słaba estetyka kodu

Wrzuciłbyś jako repozytorium.

// ADD



Jak ktoś widzi co robi to nie ma grzechu. Jak się da to czemu nie, ale nie jest to jakaś wada, którą można wytknąć jako błąd. To tak samo powinno się wymyśleć jak uniknąć white-space na początku. Bardziej już należy uważać, żeby przypadkiem nie zapisać pliku jako UTF-8 z BOM. Przezorność trochę na wyrost ;p

Jak najbardziej, jest to po prostu dobra praktyka.

Nie przeglądałem zawartości tego pliku, ale bardzo podobna klasa jest tutaj (bardzo podobnie wywoływane są parametry w funkcjach):
http://simplehtmldom.sourceforge.net/

Kolego, przepraszam bardzo, ale jak to się ma do zasadności mojego pytania, czyli optymalizacji? To że poprawie komentarz z params na param nie wpłynie w żaden sposób na wydajność klasy. W wersji skompresowanej nawet nie będzie tych komentarzy. Nie oceniasz mojego zeszytu do polskiego, żeby patrzeć na estetykę, czy przypisy na marginesie... Czy mogę liczyć na jakieś sensowne porady? Preg_match nie jest tam znów tak wiele, ale byłbym wdzięczny jakby mi ktoś wskazał choć jeden który mogę zastąpić inną, szybszą funkcją. Lub wykazał błędność mojego toku rozumowania. Ogólnie rzecz biorąc, nie chodzi o estetykę, a o użyteczność.

Jeżeli tak podchodzisz do tematu to nie mam Ci nic więcej do powiedzenia.
Umieszczasz temat w dziale "Oceny", na początku piszesz:



Później piszesz:

Wskazanie ci problemów wydajnościowych miało być dodatkiem do tematu, a nie jego głównym celem.
Głównym celem była ocena, którą na pierwszy rzut oka podesłałem.

Kod ocenia się nie tylko patrząc na jego użyteczność, chociaż podobnie jak sowiq nie widzę dla tej klasy sensu bytu.

Niestety, ale przejawiasz problem większości programistów PHP, którzy mają głęboko w poważaniu swój kod, jego estetykę i poprawność wg. standardów, a potem w przyszłości ktoś musi takie "wymiociny" przeglądać i edytować, bo komuś nie chciało się zadbać o kod i tłumaczył się tym, że użyteczność jest ważniejsza niż estetyka kodu.

Najlepiej zakoduj swoją klasę w IonCube, albo napisz wszystko w jednej linii i daj nam ponownie do oceny.
Bo przecież chodzi o użyteczność, a nie estetykę i wygląd kodu.

A błąd w twoim toku rozumowania powstał już na etapie kiedy zrodził się pomysł stworzenia tej klasy zamiast wykorzystać DOMDocument

No nic, dzięki kolego. Widzę, że bezzasadny jest dalszy rozwój projektu. Niby działa jak należy, ale za wolno, a ja nie widzę sposobu na redukcję.

Tylko czemu kod jest nieestetyczny? Hmm?

@b4rt3kk, podstawą użyteczności jest poprawnie napisany kod, a co za tym idzie np. wskazane przez @mstraczkowski błędy w komentarzach. Bo użyteczność jako pojęcie obejmuje także to w jak przystępny sposób inni będą mogli używać takiego kodu.

Osobiście również nie widzę sensu w istnieniu tego kodu z powodów wyżej wymienionych, ale jeżeli jest to dla nauki lub treningu, to jak najbardziej. Tylko wtedy nie należy piszczeć jak mała dziewczynka, bo się robi błędy

Wrzuć to na github/gist w wersji online.