Seite 1 von 1

HTML-Dokumente mit JQuery-artigem API testen?

Verfasst: Donnerstag 27. November 2008, 09:16
von sma
Rails erweitert Rubys Unittest-Rahmenwerk um eine Funktion, HTML-Dokumente mittels JQuery-artiger Selector-Strings zu durchsuchen und so bestimmte Teile zu prüfen. Scheint mir ein sehr interessantes Feature zu sein und in einem privaten Wettkampf Rails vs. Django musste ich hierbei eine Niederlage von Django eingestehen.

Gibt es eine vergleichbare Funktion für Python? Ich möchte dabei nicht XPath haben, sondern etwas, das kompatibel zu JQuery ist. Und es sollte nicht lxml-basiert sein - das will sich unter OS/X nicht installieren. BeautifulSoup wäre okay.

Eigentlich kann das doch nicht so schwer sein, oder?

Man schreibe sich einfach einen Interpreter für JavaScript, lade dann JQuery, simuliere den DOM... just kidding.

Stefan

Verfasst: Donnerstag 27. November 2008, 09:27
von Darii
Musst du selbst Programmieren, da gibts nichts vergleichbares.

PS: lxml lässt sich bei mit problemlos installieren, liegt aber evtl. an ein paar Bibiolotheken die ich über macports installiert habe.

Verfasst: Donnerstag 27. November 2008, 09:33
von sma
Darii hat geschrieben:Musst du selbst Programmieren, da gibts nichts vergleichbares.
Nun, wohlan, dann werde ich mir mal den Ruby-Code (600 LoC) anschauen, wie die das gemacht haben.
Darii hat geschrieben:PS: lxml lässt sich bei mit problemlos installieren, liegt aber evtl. an ein paar Bibiolotheken die ich über macports installiert habe.
Das wird es sein, denn...

Code: Alles auswählen

Using build configuration of libxslt 1.1.12
Building against libxml2/libxslt in the following directory: /usr/lib
src/lxml/lxml.etree.c:150:31:src/lxml/lxml.etree.c:150:31: error: libxml/schematron.h: No such file or directory
 error: libxml/schematron.h: No such file or directory
src/lxml/lxml.etree.c:1770: error: syntax error before ‘xmlSchemaSAXPlugStruct’
src/lxml/lxml.etree.c:1770: error: syntax error before ‘xmlSchemaSAXPlugStruct’
...
Stefan

Verfasst: Donnerstag 27. November 2008, 16:22
von Y0Gi
Unter Linux muss man `libxml2` und `libxslt1.1`(?) installieren (oder aktualisieren, AFAIK mit fink), damit setuptools ein Ei kompiliert. Das dürfte unter OS X nicht viel anders sein. Hast du die Libraries oder willst du ein Python-Paket mit C-Abhängigkeiten ohne Kompilierung installieren? Ich weiß nicht, wie weit du dich nun wirklich damit beschäftigt hast, aber ich lege sicherheitshalber diesen Link ans Herz.

Verfasst: Donnerstag 27. November 2008, 19:39
von sma
Ich hatte auch schon mal einen anderen Link hier gepostet, der beschreibt, wie man in einfachen 10 Schritten oder so die Bibliothek selbst installieren kann. Will ich aber nicht. Ich bin da bockig. Ich werde nicht irgendwelche Systembibliotheken unter OS/X aktualisieren, werde mir nicht fink installieren (habe mich für Macports entschieden, nutze das aber auch nicht, weil ich das als Murks empfinde, da das stundenlang kompiliert, ich brauchte aber beruflich postgres) und will Bibliotheken haben, die sich selbst um alle Abhängigkeiten kümmern und ohne Mühe installierbar sind. Andernfalls nörgel ich wie in diesem Rant.

Stefan

Verfasst: Donnerstag 27. November 2008, 19:42
von sma
Ach ja, habe einen Selector-Parser gebaut, hätte jetzt liebend gerne einen einzelnen verbindlichen XML-Standard wie bei Java. Offenbar hat ja jede Python-Lib eine andere Vorstellung, wie man aufKnoten zugreift, murks, murks, murks. Sobald ich weiß, mit welche Lib ich bevorzuge und mich noch zu unittests durchringen kann, poste ich den Quelltext irgendwo.

Stefan

Verfasst: Donnerstag 27. November 2008, 19:53
von Leonidas
sma hat geschrieben:will Bibliotheken haben, die sich selbst um alle Abhängigkeiten kümmern und ohne Mühe installierbar sind. Andernfalls nörgel ich wie in diesem Rant.
Suchst du vielleicht Ubuntu? Oder irgendein anderes Linux oder generell System mit anständigen Paketmangagement? ;) Das ist nun schon mein zweiter SCNR-Post heute, aber ich muss auch sagen, dass es mir vollständig unklar ist warum Apple sich nicht auch ein brauchbares Paketsystem zugelegt hat. Zudem das bei Apple-Produkten einfacher ist als z.B. bei Linux weil nicht so heterogen.

Verfasst: Donnerstag 27. November 2008, 20:59
von lunar
sma hat geschrieben:ohne Mühe installierbar sind. Andernfalls nörgel ich wie in diesem Rant.
lxml ist ohne Mühe zu installieren. Nur eben nicht auf deinem System, aber wenn außer die Mac-User selbst interessiert schon Mac OS X ... scnr
sma hat geschrieben:Ach ja, habe einen Selector-Parser gebaut, hätte jetzt liebend gerne einen einzelnen verbindlichen XML-Standard wie bei Java.
DOM und SAX existieren auch für Python. Da will das halt nur niemand nutzen, weil DOM und SAX umständlich und aufwendig sind, während ElementTree und insbesondere lxml.etree einfach, leicht und verständlich sind, so dass die Arbeit mit lxml sogar fast schon Spaß macht.

Im Übrigen bietet lxml auch einen Wrapper für BeautifulSoup, so dass man auch dessen – zugegebenermaßen komische – API über eine ElementTree-Schnittstelle erreicht.

Verfasst: Donnerstag 27. November 2008, 21:20
von Darii
Leonidas hat geschrieben:aber ich muss auch sagen, dass es mir vollständig unklar ist warum Apple sich nicht auch ein brauchbares Paketsystem zugelegt hat. Zudem das bei Apple-Produkten einfacher ist als z.B. bei Linux weil nicht so heterogen.
Vermutlich weil es für die meisten Benutzer unnötig ist. Mac Programme installiert man i.d.R. indem man sie in den Programme-Ordner zieht und zum deinstallieren zieht man sie auf den Papierkorb. Bei Linux würde man ohne Paketmanager völlig abdrehen. ;)

Aber es ist ja nicht so dass es keine Paketmanager gibt. macports und Fink. Der Nachteil ist bloß dass macports sourcen basiert ist(wie *bsd ports) und die Binärdistribution von Fink(=apt-get) hoffnungslos veraltet ist. Dazu kommt das ports imo im Vergleich zu apt-get echt mal scheiße ist, ka warum die BSDler da so drauf schwören.

Ansonsten gibt es aber noch andere Praktische Gründe keine Module mit externen Abhängigkeiten verwenden zu wollen. Nicht immer hat man die Möglichkeit diese zu verwenden(z.B. google appengine).

lunar hat geschrieben:DOM und SAX existieren auch für Python. Da will das halt nur niemand nutzen, weil DOM und SAX umständlich und aufwendig sind,
Vor allem ist minidom relativ broken. Irgendwie gibt es wohl die Möglichkeit der Bibliothek einzuprügeln, was sie als ID-Tag benutzen soll, aber dokumentiert ist das nirgends => unbenutzbar.

Verfasst: Donnerstag 27. November 2008, 21:23
von Leonidas
Darii hat geschrieben:Vermutlich weil es für die meisten Benutzer unnötig ist. Mac Programme installiert man i.d.R. indem man sie in den Programme-Ordner zieht und zum deinstallieren zieht man sie auf den Papierkorb. Bei Linux würde man ohne Paketmanager völlig abdrehen. ;)
Bei Linux könnte man sowas durchaus auch haben. Das Problem ist weniger der Paketmanager, sondern dass die Pakete gegen verschiedene Versionen von Libs gelinkt sind, aber das Problem hat man unterm Mac ja eher weniger.

Verfasst: Donnerstag 27. November 2008, 21:54
von lunar
Darii hat geschrieben:Dazu kommt das ports imo im Vergleich zu apt-get echt mal scheiße ist, ka warum die BSDler da so drauf schwören.
Nur, weil man kompilieren muss?
Ansonsten gibt es aber noch andere Praktische Gründe keine Module mit externen Abhängigkeiten verwenden zu wollen. Nicht immer hat man die Möglichkeit diese zu verwenden(z.B. google appengine).
Das mag wohl sein. Allerdings trifft das nur auf eine Minderheit der Programme zu. Für Anwendungen, bei denen man die Möglichkeiten hat, externe Bibliotheken zu nutzen, sollte man das auch tun, wenn sie – wie im Falle lxml – merkliche Erleichterung verschaffen.

Verfasst: Donnerstag 27. November 2008, 21:56
von Darii
lunar hat geschrieben:
Darii hat geschrieben:Dazu kommt das ports imo im Vergleich zu apt-get echt mal scheiße ist, ka warum die BSDler da so drauf schwören.
Nur, weil man kompilieren muss?
Deinstallieren, updaten etc. ist sehr krampfig. Kann mich nicht erinnern, dass portage genauso war.

Verfasst: Dienstag 9. Dezember 2008, 11:10
von veers
And here it is:
http://pypi.python.org/pypi/pyquery

Nun brauchen wir noch noch ein kleines Testframework dazu ;)

- Jonas