Eine Art Regex-Engine für HTML - gibt es das schon? (Fragen zu Perl-Modulen)

[thread]17655[/thread]

Eine Art Regex-Engine für HTML - gibt es das schon?

Leser: 23

Articles: hide open all | hide show old branches

+5 replies
flowdy

2012-08-11 23:02
User since
2012-08-03
45 Artikel
BenutzerIn
Hallo,

für meine Diplomarbeit vor fünf Jahren hatte ich ein Modul namens HTML::StreamFisher geschrieben. Es handelt sich dabei um eine reverse Template-Engine, das heißt, der Nutzer definiert kein Templates um Webseiten zu produzieren, sondern um existierendes HTML vom Modul lesen zu lassen und eine quasi fertige Datenstruktur aus HoA und HoH zurück zu bekommen, die er dann wie auch immer weiter verarbeitet. Das dazu definierte Template entspricht natürlich nicht dem Template auf der Serverseite, also kein "Reengineering", es ist soweit reduziert, dass das Auffinden relevanter Inhalte gerade noch maschinell möglich ist und "Beifang" (Inhalte, die strukturell dem Muster entsprechen, ohne die gewünschte Information zu enthalten) so gut wie möglich vermieden wird. Es ist eigentlich der Regex-Engine nachempfunden, arbeitet eben auf HTML-Nodes statt auf Zeichen.

Ich überlege, ob ich die Arbeit daran wieder aufnehme. Es gibt noch ein paar Features, die dem Modul gut zu Gesicht stünden und sinnvoll wären (wiederkehrende Subpatterns à la (...)*/+(?) etwa), und außerdem hat das Teil garantiert noch Bugs, die das Pech hatten, dass sie mir nicht - von den Gutachtern oder mir selbst in der Verteidigung entdeckt - die Gesamtnote vermiesen konnten.

Aber zuvor die obligatorische Frage:
- Seht ihr Bedarf?
- Könnte sich die Arbeit eurer Meinung nach lohnen?
- Kennt ihr vergleichbare Module im CPAN?
- Oder ist jeder mit HTML::TreeBuilder und Konsorten zufrieden?
Dieses hätte mich von der Entwicklung von HTML::StreamFisher auch nicht abgehalten aus dem einfachen Grunde, dass sich sich das prozessorale Navigieren durch den Baum so viel schlechter von Laien (wie meine Betreuer, die im Bibliothekswesen firm sind aber nicht in der Programmierung) überblicken und verstehen lässt als Musterdeklarationen, die im gewissen Sinne nichts anderes als HTML sind - in der Tat wird im Modul nicht nur die Webseite, sondern auch diese Musterdeklarationen durch den HTML::TokeParser vorverarbeitet.

Viele Grüße,
flowdy
package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;
- +4 replies
- GwenDragon
  
  2012-08-12 17:30
  
  User since
  2005-01-17
  14748 Artikel
  Admin1
  
  Lade es doch mal als Anhang hoch.
  Interessiert sicher einige von uns.
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - +3 replies
  - flowdy
    
    2012-08-13 22:01
    
    User since
    2012-08-03
    45 Artikel
    BenutzerIn
    
    Tut mir leid, so wie der Code ist, kann ich mich nicht dazu überwinden ihn zu veröffentlichen - schließlich habe ich seit dem Erfahrungen mit Perl und v.a. gutem Code gesammelt und würde heute anders coden. Müsste ihn also überarbeiten, aber dazu müsste ich wissen ob sich das lohnt. Hm, irgendwie Henne+Ei.
    
    Hat wer praktische Erfahrungen mit Template::Extract oder Text::Scraper gemacht? Frage mich, warum ich die "damals" nicht gefunden habe (oder habe ich? k.A.), noch interessanter aber ebenso nutzlos ist die Frage, ob sie mir 4 Wochen außerplanmäßiges Programmieren mit dem Bangen im Hinterkopf, ob ich den eigentlich wichtigeren Teil der Arbeit trotzdem noch schaffe, erspart hätten.
    
    Anhand der Dokumentation gehen beide den gerade umgekehrten Ansatz: Sowohl Template::Extract als auch Text::Scraper kompilieren das Template in eine Regex. Die würde sehr wahrscheinlich monströs, je nach Komplexität des Templates, armes Schw**n der Anwender, der die debuggen muss. HTML::StreamFisher dagegen funktioniert in Anlehnung an die Regex-Engine wie ein Getriebe aus zwei ineinander greifenden Zahnrädern, zwei HTML::TokeParser-Instanzen, die eine nudelt das Template durch, die andere den Quelltext, und abhängig vom Vergleich zwischen Template- und Quelltext-Node wird erstere vorgesteuert oder nicht. Für IF-ELSE-Alternativenketten, die übrigens weder Template::Extract noch Text::Scraper laut Doku unterstützen, hatte ich eine sehr rudimentäre Art von Backtracking implementiert. Dafür beherrscht HTML::StreamFisher noch keine untergeordnete Schleifen.
    
    Welcher Ansatz verspricht in euren Augen mehr Potenzial? Template-nach-Regex-Kompilieren oder etwas Regex-Engine-Artiges für HTML-Token?
    
    Viele Grüße,
    flowdy
    package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;
    - +2 replies
    - topeg
      
      2012-08-13 23:15
      
      User since
      2006-07-10
      2611 Artikel
      BenutzerIn
      
      Damit ich es richtig verstehe. Ich habe HTML da kopiere ich mir die Interessanten teile heraus, markiere die Stellen, die mich interessieren, und der Rest macht das Modul?
      
      Wenn dem so ist, dann ist es durchaus interessant. Ich nutze schon seit längerem ein Programm was die InternetSeiten von Fernsehsender parst und daraus meine Fernsehzeitschrift generiert.
      Das möchte ich noch nicht veröffentlichen, da unter anderem das Parsen der Seiten nicht sonderlich Komfortabel gelöst ist (HTML::TreeBuilder).
      
      Bei Template::Extract und Text::Scraper müssen die Datenstrukturen nach bearbeitet werden. Das ist für einen Editierenden, der nicht gut Programmieren kann nicht einfach. HTML::TreeBuilder ist da vergleichbar.
      Richtig Kompliziert wird es wenn viele Templates und Seiten bearbeitet werden sollen. Da gibt es nichts.
      
      Idealer weise sollte man in den Templates gesuchten Stellen benennen können. Weiterhin wäre eine Signal-Struktur von Vorteil. Damit kann der Programmierer die Datenstruktur selbst bestimmen und zusammen mit den benannten Such-Stellen die Struktur erstellen, die er braucht.
      
      Mal so aus der Hüfte geschossen, wie ich mir ein Interface vorstellen würde.
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
      
      use Template_Engine; use LWP::Simple; my $template=Template_Engine->new(); $template->add_template( Parse_Datum => eval{local $/=undef; <DATA>} ); $template->signal_connect('Datum' => &datum, 'optionale Werte an die Funktion'); $template->parse( Parse_Datum => get('http://example.org') ); sub datum { my $wert=shift; my @path=@{shift}; my $opts=shift; print "@path => $wert\n"; return 1; } __DATA__ [%foreach%] <div id="tag"> [%...%] [%foreach%] [%...%] <div class="datum">[%value path='/Tag/Datum'%]</div> [%...%] [%endfor%] [%...%] </div> [%endfor%]
      
      Mit einer Ausgabe wie:
      
      Code: (dl )
      
      1 2 3 4
      
      Parse_Datum Tag Datum -> 19.2.2010 Parse_Datum Tag Datum -> 11.6.2024 Parse_Datum Tag Datum -> 25.5.1999 Parse_Datum Tag Datum -> 3.3.2003
      
      Oder mit so einem Template:
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13
      
      [%foreach path="/Tage"%] <div id="tag"> [%...%] [%foreach%] [%...%] <p>[%value path="Name"%]</p> [%...%] <div class="datum">[%value path='Datum'%]</div> [%...%] [%endfor%] [%...%] </div> [%endfor%]
      
      Code: (dl )
      
      1 2 3 4
      
      Parse_Datum Tage Datum -> 19.2.2010 Parse_Datum Tage Datum -> 11.6.2024 Parse_Datum Tage Datum -> 25.5.1999 Parse_Datum Tage Datum -> 3.3.2003
      
      Und wenn für "Name" auch eine Funktion definiert wurde:
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8
      
      Parse_Datum Tage Name -> Dienstag Parse_Datum Tage Datum -> 19.2.2010 Parse_Datum Tage Name -> Montag Parse_Datum Tage Datum -> 11.6.2024 Parse_Datum Tage Name -> Donnerstag Parse_Datum Tage Datum -> 25.5.1999 Parse_Datum Tage Name -> Sonntag Parse_Datum Tage Datum -> 3.3.2003
      
      Schön wäre wenn man alle Tags so behandeln könnte.
      
      So was gibt es nicht, soweit ich weiß. Das wäre auch für andere Interessant.
      - flowdy
        
        2012-08-14 21:17
        
        User since
        2012-08-03
        45 Artikel
        BenutzerIn
        
        Ja topeg, in diese Richtung geht das. Im Template selbst stehen nur speziell markierte Wildcard-Bezeichner sowie dazu etwaige Quantifier, UND- und ODER-Verschaltungen. Alles andere dazwischen ist HTML-Code.
        
        Darüber hinausgehende Direktiven und diesen beigeordnete Attribute/Einstellungen wie "path=..." kennt HTML::StreamFisher nicht. Was ein Bezeichner repräsentiert, wird in einem eigenen Hash bzw., mal sehen, einem HTML::StreamFisher::Template::XYZ-Objekt unter diesem Bezeichner definiert (d.h. außerhalb des Wurzeltemplates mit dem Schlüssel 'MAIN'). Also ob es sich um ein Untertemplate handelt oder um meinen String, und ob dieser String noch speziell zu filtern, in mehrere Teile aufzusplitten und/oder an einen Callback zu übergeben ist und so weiter.
        
        Ich bin mir nicht sicher, ob das bei komplexeren Templates übersichtlicher ist als der Ansatz mit den In-Place-Direktiven. Wird sich herausstellen; ich habe jedenfalls kein Interesse, die halbe TT- bzw. die Perl-Syntax nachzubauen (TT selbst ist ja eigentlich schon Perl, nur halt in Großbuchstaben), die Regex-Engine reicht mir schon. Auch die Entwickler von Template::Extract und Text::Scraper haben sich nur auf einen Teil beschränkt.
        
        Naja, also bei Zeit und Gelegenheit kümmere ich mich um HTML::StreamFisher.
        
        Viele Grüße,
        flowdy
        package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;

View all threads created 2012-08-11 23:02.