Text in HTML mit p-Tags umwandeln

Peter Schwab am 01.12.2002 – 11 Kommentare

(Michael Charlier möge mir die Entführung seiner «Geschichte vom kleinen Blindtext» verzeihen, aber ich finde sie viel nüddeliger als die ewige LoremIpsumerei.)

Download Skript

Kommentar von: molily
Eingetragen am: 08.12.02 um 10.47 Uhr

Hallo,

Es besteht keine Notwendigkeit, dass in den Zeilen 5, 9 und 13 preg_*-Funktionen verwendet werden, da hier Reguläre Ausdrücke unnötig sind. Wenn ich das richtig überblicke, ist auch das preg_replace() in Zeile 15 unnötig, da hier nur $newmessage.='

'.$paragraph.'

'; durchgeführt wird. Das Script ist mit Sicherheit dreimal so langsam wie es im optimalsten Fall sein müsste.

Der Mix aus CSS- und HTML-Formatierungen ist auch sehr eigen... Transitional halt, was soll jetzt daran herausragend sein? Es ist nunmal gemeiner quirksiger Transitional-Code mit XML-Syntax, toll ist das nicht.

Wieso wird hier überhaupt mit zip-Downloads gearbeitet, die kurzen Scripts könnte man auch als text/plain anbieten, zudem ist eine serverseitige gzip-Komprimierung möglich, sodass die zip-Datei entfällt.

Grüße, M.

Kommentar von: Robert
Eingetragen am: 13.12.02 um 23.36 Uhr

@molily

Das Script ist mit Sicherheit dreimal so langsam wie es im optimalsten Fall sein müsste.

lol

sorry, aber ich habe es gerade mal mit einem Timer versehen und getestet und dabei kam im Schnitt dieses Ergebnis dabei raus: 0.0029... Was macht das für einen Unterschied ob 0.0029 oder ein bisschen mehr, das sind Millisekunden. Die machen doch keinen arm oder?

Zudem finde ich das Script nicht einmal so schlecht. Man könnte es verbessern, dem ist klar, das kann man aber bei jedem OpenSource-Code. Der eine mag eben den Stil, der andere den. Zumindest funktioniert das Script und dann ist es jedenfalls nicht einmal falsch :-)

Kommentar von: molily
Eingetragen am: 16.12.02 um 11.37 Uhr

Hallo, Robert,

Das Script ist mit Sicherheit dreimal so langsam wie es im optimalsten Fall sein müsste. sorry, aber ich habe es gerade mal mit einem Timer versehen und getestet und dabei kam im Schnitt dieses Ergebnis dabei raus: 0.0029... Was macht das für einen Unterschied ob 0.0029 oder ein bisschen mehr, das sind Millisekunden. Die machen doch keinen arm oder?

Ich habe nicht gesagt, dass das Script langsam läuft, es ist generell ineffektiver gebaut als nötig und läuft langsamer als es müsste. Natürlich, es funktioniert. Wenn es darum geht, dass es in akzeptabler Geschwindigkeit die Aufgabe löst, ist es sicherlich auch in dieser Form benutzbar. Unter Belastung wird sich diese Variante jedoch als problematisch erweisen. Dass das für die meisten Anwendungsfälle ohne Belang ist, wollte ich nicht bestreiten. Das ändert aber meiner Meinung nach nichts daran, dass man den Code unabhängig vom späteren Einsatz so »simple and stupid wie möglich halten sollte. Womöglich stimmt meine Vermutung sogar, dass das Script dreimal so langsam wie nötig läuft - natürlich ist die Relevanz dieser Aussage nicht in allen Fällen gegeben, und der absoluten Wahrheit[tm] muss sie auch nicht entsprechen.

Zudem finde ich das Script nicht einmal so schlecht.

Ich wollte das Script nicht »schlechtmachen«, sondern lediglich darauf aufmerksam machen, dass das Script komplizierter als nötig ist, wodurch einem PHP-Anfänger beispielsweise das Verständnis verwehrt werden könnte.

Man könnte es verbessern, dem ist klar, das kann man aber bei jedem OpenSource-Code.

Aufgrund der vorhandenen Kommentierungsfunktion habe ich Anmerkungen (beziehungsweise Verbesserungsvorschläge, sofern sie augegriffen werden, vom Leser wahrscheinlich schon) gemacht. Nicht mehr und nicht weniger.

Der eine mag eben den Stil, der andere den.

Ich glaube nicht, dass das eine Stilfrage ist. Warum umständlich, wenn es auch einfach geht... Sicher, mit subjektivem Geschmack lässt sich alles rechtfertigen. Diesen will ich auch niemanden wegnehmen.

Zumindest funktioniert das Script und dann ist es jedenfalls nicht einmal falsch :-)

Das halte ich nicht für das einzig entscheidende Kriterium. Aber diese Diskussion wird OT. Besser f'up2p.

Grüße, Mathias

Kommentar von: Peter Schwab
Eingetragen am: 09.01.03 um 19.12 Uhr

Mein lieber Molly, eh.. Molily!

Da hast Du es mir ja so richtig gegeben! :o)

Aber Dein Wunsch sei Befehl, hier ist die Funktion noch mal fit und schlank ohne die Dir so verhassten reg. Ausdrücke.

function text2html($message) {

$message = str_replace("\r", "", $message);

$message = htmlentities($message);

$parts = explode("\n\n", $message);

foreach ($parts as $paragraph) {

$paragraph = str_replace("\n", "

\n", $paragraph);

$newmessage = "<p>" . $paragraph . "</p>";

$newmessage .= "\n";

}

return $newmessage;

}

Ein gutes, neues Jahr wünsche ich noch

+peter+

Kommentar von: Basti
Eingetragen am: 03.06.04 um 01.27 Uhr

Versteh ich nicht. Warum splittest du den Text an doppelten Newlines auf, jagst jeden dieser Happen durch eine Schleife und überschreibst dann in dieser Schleife jedesmal die in den vorigen Durchläufen erstellte Variable?

Ich werd nicht so ganz schlau daraus, was du da nun tatsächlich vorhast (vielleicht steht es ja im ZIP-Archiv, das hab ich mir nicht angeschaut).

Wer einfach einen doppelten HTML-Zeilenumbruch in einen Absatz verwandeln möchte, der kann das ganz einfach so machen:

$tmp_array = preg_split('|\s*

\s*

\s*|', $string);

 

$result  = '<p>';

$result .= implode("</p>\n<p>", $tmp_array);

$result .= '</p>'; 

Hat man keinen HTML-Text vorliegen, sondern möchte an 'normalen' Zeilenumbrüchen (ASCII 10 oder/und 13) die Absätze setzen, dann kann man es so umschreiben:

$tmp_array = preg_split('|\s*\n\s*\n\s*|', $string);

 

$result  = '<p>';

$result .= implode("</p>\n<p>", $tmp_array);

$result .= '</p>';

Dann sollte man allerdings zuvor noch die Windows- und Mac-Zeilenumbrüche in das Un*x-Format bringen (je nachdem halt, wo die Daten herkommen):

$string = str_replace("\n\r", "\n", $string);

$string = str_replace("\r", "\n", $string);

...und, um noch meinen Senf zu der uralten Diskussion oben abzugeben:

Ich sehe auch keinen Sinn darin, von zwei alternativen Wegen, von denen keiner aufwändiger ist, als der andere den Performancefresser zu wählen, auch, wenn absehbar ist, dass es sich letztlich nur um Millisekunden handeln wird.

Und ich hätte auch lieber eine Code-Ansicht, als ein ZIP-Archiv. Wie groß muss der Schnipsel sein, dass der Zeitaufwand fürs lokale Speichern, Entpacken (ggf. Komp.-App. öffnen) und später ggf. wieder Löschen den für den größeren Download übersteigt?

Und nochwas: Lasst doch die Einrückungen im Code-Teil der Kommentare stehen...

Basti

Kommentar von: Basti
Eingetragen am: 03.06.04 um 01.40 Uhr

...oops, der "Windows-Zeilenumbruch-Umwandler" kann natürlich raus, denn er enthält ja die Newlines und die Carriage Returns werden durch die \s* im RegExp abgefangen.