Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Andreas Borutta Newsgroups: de.comp.lang.php Subject: Re: =?iso-8859-1?Q?=22Prettify=22_=28Umbr=FCche=2C_Leerzeichen=29?= =?iso-8859-1?Q?_vor_dem_Ausliefern?= Date: Thu, 11 Dec 2025 14:07:31 +0100 Organization: A noiseless patient Spider Lines: 127 Message-ID: <12gr78hyiu35l.dlg@borumat.de> References: <1e5jhd9og7z4l.dlg@borumat.de> <1t6909b12ei32e282n3e8%sfroehli@Froehlich.Priv.at> <1f6z9pqbuv8xj$.dlg@borumat.de> <1t6909e0efi34eabbn3e8%sfroehli@Froehlich.Priv.at> <2gsf4lr3fd6.dlg@borumat.de> <14269q1gcv61z$.dlg@borumat.de> <10gbrbh$29n7o$1@dont-email.me> <10h43qc$3gdng$1@dont-email.me> <3t6935d6a3i3ebed8n3e8%sfroehli@Froehlich.Priv.at> <1t6936922cia8032n3e8%sfroehli@Froehlich.Priv.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Injection-Date: Thu, 11 Dec 2025 13:07:32 +0000 (UTC) Injection-Info: dont-email.me; posting-host="d02994f8b98422c49de59027e2454f56"; logging-data="2348450"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19mPy7rub/N5t9ttT/Hneom1bp/2uuLQP8=" User-Agent: 40tude_Dialog/2.0.15.41de (ce380df5.166.283) Cancel-Lock: sha1:AAd+AGDg+/mCdhhYwHb1yf9scEE= Xref: csiph.com de.comp.lang.php:5009 Stefan Froehlich: > On Sun, 07 Dec 2025 21:55:57 Andreas Borutta wrote: >> Stefan Froehlich: >>> On Sun, 07 Dec 2025 20:09:34 Andreas Borutta wrote: >>>> Arno Welzel: >>>>> Andreas Borutta, 2025-12-04 14:21: >>>> Wir reden ja über das Konzept von Erweiterungen. Ich nahm an, >>>> dass es für den Standardfall "Erweiterung X anwenden" den >>>> fertigen Befehl gibt. > >>> Naja, es sind doch eh nur drei Befehle: Daten einlesen, Daten >>> verarbeiten, Daten ausgeben: > >>>| $tidy->parseString($html, $config, 'utf8'); >>>| $tidy->cleanRepair(); >>>| return (string) $tidy; > >>> Der ganze Rest drumherum ist Initialisierung, Prüfung und >>> Fehlerverarbeitung. Fast alles davon könntest Du theoretisch auch >>> weglassen, aber wenn dann irgendetwas nicht nach Plan läuft, >>> fliegt Dir das Programm um die Ohren - das ist kein Gewinn. > >> Sollte denn die Aufgaben Initialisierung, Prüfung und >> Fehlerverarbeitung nicht Bestandteil jeder Erweiterung oder des >> aufrufenden Moduls sein. > > Sind sie ja auch, nur: > >> Mir leuchtet bisher eine Architektur nicht ein, wo der jeder >> Anwender einer Erweiterung "das Rad neu erfindet" - nur um die >> Erweiterung aufzurufen. > > ...ist es dennoch keine Neuerfindung des Rades: Teilweise stellen > sich zusätzliche Fragen, und häufig müssen diese Dinge auf jeder > Ebene innerhalb einer Software stattfinden. Schauen wir es uns an: > >| // Prüfe ob Tidy verfügbar ist >| if (!class_exists('tidy')) { >| return $html; >| } > > Das kann naturgemäß nicht innerhalb von tidy passieren. Lässt Du > diese Zeilen weg, passiert nichts schlimmes - solange tidy > installiert ist, andernfalls stürzt die Software einfach ab (bzw. > passiert das, was irgendeine Fehlerroutine weiter oben vorsieht, und > das wird ziemlich sicher nicht die Rückgabe des unformatierten > Quelltexts sein). Drei Zeilen, die praktisch nichts kosten, sich > ggf. aber lohnen. > >| // Lade Config >| $iniFile = __DIR__ . '/tidy.ini'; >| $config = file_exists($iniFile) >| ? parse_ini_file($iniFile, false, INI_SCANNER_TYPED) >| : []; > > Auch die Initialisierung von tidy kann naturgemäß nicht in tidy > passieren. Brauchst Du keine (via externer Datei durchgeführte) > Initialisierung, kannst Du diese Zeilen auch einfach weglassen, aber > es ist IMO durchaus sinnvoll, in einer generischen Erweiterung die > Möglichkeit dafür vorzusehen. Auch das kostet ja praktisch nichts. > >| // Fallback auf Default-Config wenn Parse fehlschlägt >| if ($config === false) { >| $config = [ >| 'indent' => true, >| 'wrap' => 0, >| 'output-html' => true, >| ] ; >| } > > Das mag der am ehesten redundante Teil der Geschichte sein: Es gibt > eine Konfigurationsdatei, aber sie ist kaputt. Hier könnte man auch > einfach auf [] zurückfallen, so wie es bei fehlender Datei getan > wird. Geschmacksfrage, aber auch hier: Kostet fast nichts, kann man > halten, wie man möchte. > >| // Fehlerbehandlung >| if ($tidy->errorBuffer) { >| // Optional: Logge Tidy-Warnungen >| // error_log('Tidy warnings: ' . $tidy->errorBuffer); >| } > > Die Fehlerbehandlung passiert innerhalb von tidy - tidy schreibt die > Fehlermeldungen in einen Puffer, aber tidy kann nicht wissen, wie > damit umgegangen werden soll. Wer sie nicht braucht, kann sie auch > ignorieren, aber sie ggf. weiterzureichen erscheint nicht ganz dumm. > (Kostet auch hier wieder nicht viel, zumal im Regelfall ja keine > Meldungen vorhanden sein sollten). > >| try { >| [...] >| } catch (\Exception $e) { >| // Bei Fehler: Original-HTML zurückgeben >| return $html; >| } > > Und zu guter Letzt überlegen wir uns noch, was passiert, wenn tidy > selbst fehlerhaft ist, Lassen wir unsere Software dann einfach > abstürzen (so wie oben, beim Fehlen von tidy), oder tun wir so, als > wäre alles in Ordnung und geben den unformatierten Quelltext zurück? > Auch diese Entscheidung kann nur lokal getroffen werden, und für die > zweite, IMO zu bevorzugende Option sind neuerlich ein paar wenige > Zeilen Code erforderlich. > > In Summe also 5x mehr Schutzmaßnahmen als eigentliche Arbeit, und > das wiederholt sich vermutlich ganz ähnlich auf den Ebenen darunter > (innerhalb von tidy) und darüber. Erstmal vielen Dank für deine Erläuterungen : ) Vielleicht gibt es noch ein Missverständnis zu meiner Frage. Ich vertraue euch erfahrenen Programmierern selbstverständlich, dass der Code sinnvoll ist und die damit gelösten Aufgaben auch. Mir ist nur nicht klar, dass es dafür keine "Schicht" gibt, die fix und fertig bereit steht. Weil diese Aufgaben für jeden anfallen, der Tidy nutzen möchte. Aber wir müssen das auch nicht weiter vertiefen. Ich muss eh hinnehmen dass es diese "Schicht", diese "Architektur" nicht gibt. Andreas -- http://fahrradzukunft.de