EL für HtmlInputProcessor

  • Affected App
    WoltLab Suite Core

    Kein Fehler und auch kein zwingendes Problem, aber ich hätte gerne einen EL beforProcess@HtmlInputProcessor mit der Möglichkeit dort das HTML zu bearbeiten bevor es verarbeitet wird.

  • Ich will html-code in eigenen metacode umwandeln ohne dafür explizit in den redactor eingreifen zu müssen um das zu tun.

    Nutze ich beforeProcess@HtmlInputNodeProcessor muss ich zunächst den purifyer alle attribute schützen lassen obwohl es genügen würde dies nur für meine eigenen meta codes zu tun.

    Im Grunde stört mich nur dass ich keine Möglichkeit habe etwas zu unternehmen bevor der Purifyer alles zerlegt (denn das hat er mir viel zu häufig bei meinen bisherigen Tests) :P

  • Das weiß ich, muss ich ja auch tun für meine meta tags.

    Nur ist es deutlich komplexer verschiedene attribute zuerst zuzulassen und dann erst alles zu validieren und dann nochmals selbst alles wieder zu entfernen was nicht valide war, als zunächst alles zu validieren und dann purifyer alles rauswerfen zu lassen was ich nicht umgewandelt habe.

    • Official Post

    Der von mir aufgezeigte Weg ist bewusst so gewählt, er mag zwar an einigen Stellen je nach Vorhaben etwas umständlicher sein, sorgt aber für eine saubere und vorhersehbare Verarbeitung. Ein zusätzliches Event um dies alles zu umgehen wird es daher nicht geben, das ist es schlicht nicht wert.

  • Und an welcher Stelle würde man dann reinen text am besten in meta code umwandeln ?

    Denn das ist mir dann bisher nicht ganz klar, bei dem Event hab ich ja, soweit ich das sehe, nur Zugriff auf den Dom, kann zwar das HTML auslesen aber nicht direkt manupulieren oder hab ich da etwas übersehen ?

  • Naja, ich stehe noch immer vor der frage wie ich am effizientesten nach einem String im Dom suchen kann.

    Die eine Variante wäre es den Dom als string ausgeben zu lassen, alles zu ersetzen, neu zu parsen und dann den neu original dom durch den neu geoparsten zu ersetzen was ich aber als unschön empfand.

    Also dachte ich darüber nach über den dom zu iterieren und in allen text nodes danach zu suchen und dann nur dort den dom zu manipulieren wo ich auch wirklich meinen gesuchten string finde.

    Ein entspechender iterator wäre da hilfreich, auch wenn mir klar ist dass man dies auch über eine reguläre rekursion lösen kann, fand die lösung nur unschön und hätte daher einen iterator gewünscht.

  • OK, hab die Lösung gefunden, hatte nicht an xpath gedacht, $this->htmlInputNodeProcessor->getXPath()->query('//text()') löst mein Problem :D

  • Jap, genau so nen Beispiel habe ich gesucht, stand wie gesagt etwas auf dem schlauch da ich mich zu sehr auf die normalen Dom möglichkeiten versteift hatte und an alternativen nicht gedacht hatte.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!