Parser to dobry pomysł, tyle, że muszę podobny zabieg zrobić na fragmencie css i do tego użyłem regexp’ów - wieć pomyślałem, że do html’a też użyję regexpów.
Tomash, to w takim razie można to samo powiedzieć o każdym regexpie, który jest czymś bardziej skomplikowanym niż /.*/. Dla mnie sprawa jest prosta. Jeśli zagmwatwany fragment kodu jest konkretnym, wydzielonym kawałkiem (dajmy na to ubrany w metodę), okraszony komentarzem, która wyjaśnia co jest na wejściu, a co na wyjściu + ew. testy to nie widzę problemu. Jeśli przyjdzie na to czas/chęci/potrzeba zawsze mogę go przepisać. Wbrew pozorom nie jest ten kod jakiś skomplikowany (trzeba czytać oczywiście partiami, a nie jako całość).
Bajizas. Hosiowiak NIGDY nie parsuje się htmla regexpami NIGDY. Po to jest nokogiri. Tak wiem że jest dużo regexpów które pozwolą na tym konkretnym kodzie ale za chwilę się z ziaziają. Dawanie zadań w których celem jest znalezienei regexpa do HTMLa jest świadectwem niekompetencji dającego zadanie.
@Świstuk: Ale ja nie dałem “zadania” tylko zadałaełm pytanie. Z reguły każdy kto zadaje pytanie nie jest w danym momencie “kompetenty” - to dział “Potrzebna pomoc” a nie “Ociekasz zajebistością ? Pokaż swoje mojo.” Tak czy inaczej dzieĸi za podpowiedzi odnośnie parsera, ten regexp póki co działa na moim html’u, może się nie ziaziaje, jak znajdę chwilę to zamienię na parser i wszyscy będą zadowoleni.
“Create a regular expression ® in Ruby to achieve the following”. Jak dla mnie to brzmi wybitnie jak zadanie. Dlatego nazwałem to zadaniem. Proszę się nie czepiać doboru słów tylko treści ewentualnie.
Puenta była jedna: o ile poszczególne regexpy będą działać na pewnym ograniczonym podzbiorze HTML o tyle nie jesteś w stanie napisać regexpa działającego na wszystkie(w szczególości bardzo bardzo ciężkie jest sprawdzenie czy dany fragment nie jest w CDATA albo komentarzu) , dlatego trzeba się zaopatrzyć w nokogiri.
[quote=Świstak]“Create a regular expression ® in Ruby to achieve the following”. Jak dla mnie to brzmi wybitnie jak zadanie. Dlatego nazwałem to zadaniem. Proszę się nie czepiać doboru słów tylko treści ewentualnie.
Puenta była jedna: o ile poszczególne regexpy będą działać na pewnym ograniczonym podzbiorze HTML o tyle nie jesteś w stanie napisać regexpa działającego na wszystkie(w szczególości bardzo bardzo ciężkie jest sprawdzenie czy dany fragment nie jest w CDATA albo komentarzu) , dlatego trzeba się zaopatrzyć w nokogiri.[/quote]
Nie wiem czy w ogóle przeczytałeś ten problem, czy od razu bez myślenia Ci się włączył tryb: “HTML + regexp? fuuuuuu! Killll!”, ale zauważ, że tam mają być znalezione tylko pewne specyficzne części HTMLa (id="…", class="…"), a tutaj już regexpy bez problemu dadzą radę.
@drogus: To przeczytaj jeszcze raz puentę.
Nie jesteś w stanie sprawdzić czy atrybut nie jest w komentarzu na przykład przy użyciu Regexpa. nie wspominajac o tonie znaków escapujących które mogą być użyte. Więc generalnie regexpom używanym do parsowania HTMLa mówimy NIE.
Szczególnie że jak dla mnie Nokogiri::HTML(tu_html).search(’#tu.na.przykład.selektor.css’).map(&:attributes) jest o tonę prostszy i bardziej czytelny niż regexp potrzebny do tego samego zadania.
[quote]Some people, when confronted with a problem, think
“I know, I’ll use regular expressions.” Now they have two problems.[/quote]
Co ciekawe, nikt nie zadał podstawowego pytania:
Hosiawak - ten HTML, który obrabiasz jest z zewnątrznego źródła, czy sam go generujesz?
[quote=Świstak]@drogus: To przeczytaj jeszcze raz puentę.
Nie jesteś w stanie sprawdzić czy atrybut nie jest w komentarzu na przykład przy użyciu Regexpa. nie wspominajac o tonie znaków escapujących które mogą być użyte. Więc generalnie regexpom używanym do parsowania HTMLa mówimy NIE.
Szczególnie że jak dla mnie Nokogiri::HTML(tu_html).search(’#tu.na.przykład.selektor.css’).map(&:attributes) jest o tonę prostszy i bardziej czytelny niż regexp potrzebny do tego samego zadania.[/quote]
Zdaję sobie z tego sprawę, np. poniższy kod html zostanie zmieniony przez tego regexpa w miejscu gdzie nie powinien być:
<div>We have several documents with id="id" and class="class"</div>
Podsumowanie wątku (dla przyszłych pokoleń ) : do parsowania HTML’a używamy Nokogiri/Hpricot a nie wyrażeń regularnych.
Już jest wygenerowany i się nie zmienia, dlatego będąc świadomy potencjalnych problemów użyłem tego regexp’a i mogę mimo tego spać spokojnie w nocy
Jeszcze słówko wyjaśnienia dlaczego muszę zmieniać html’a: Otóż kod html + css jest tak przygotowany, że wyświetla 1 stronę na raz (powiedzmy A4). Jeśli chciałbym sobie wyświetlić 2 strony (z różną zawartością ale używając tego samego html+css) to wstawiam kod html+css dotyczący drugiej strony poniżej tego pierwszego (powiedzmy jakiś div id=wrapper) i w tym momencie mam konflikt id’ków i klas z css (reguły css’a dotyczące tylko jednej strony zostają użyte na wszystkich stronach) - stąd moja próba automatycznego rozdzielenia id/class na poszczególne strony nadając im unikalne nazwy w momencie generowania dokumentu.