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