Arch Linux

Hervorhebungen und Umbrüche in Zitaten, sowie das Bearbeiten von Postings

Dirk

Ich habe gerade einen News-Artikel hier im Forum geschrieben, wo ich ein mehrere Absätze umfassendes Zitat verwendet habe, das ich gekürzt habe, und in dem ich für die Meldung wichtige Stellen mittels einfacher Hervorhebung (''text'') hervorgehoben habe.

Nach dem Absenden (es gibt ja immer noch keine Vorschaufunktion!) musste ich den Artikel allerdings noch mal bearbetein und auf mehrere Zitat-Tags aufteilen, weil das Forum durch das Ersatzlose Weglassen von Absätzen im Zitierten Text, diesen komplett unleserlich machte.

Zusätzlich ist mir aufgefallen, dass die hervorhebungen ganz offensichtlich fehlerhaft sind. Einfache Hervorhebungen sind nämlich fett und kursiv, stärkere Hervorhebungen sind lediglich fett.

Wäre es nicht Sinnvoller, einfache Hervorhebungen kursiv, und stärkere Hervorhebungen fett zu machen, anstatt einfache Hervorhebungen fett UND kursiv (also RICHTIG stark hervorgehoben) und starke Hervorhebungen lediglich fett (im Vergleich zum fetten und kursiven Text der einfachen hervorhebungen eher schach hervorgehoben wirkend) zu machen?

Und welcher tiefere Sinn steckt eigentlich dahinter, Textformatierungen bezüglich der Zeilenumbrüche – bzw. Absätze – in Zitaten ersatzlos zu streichen?

… Dass beim Bearbeiten eines Postings sämtlicher Text komplett zusammengestaucht wird, und nur noch Absätze im Fließtext übrig bleiben (außer bei Zitaten), liegt wohl daran, dass der Text nicht ungeparst in die Datenbank geschrieben wird, sondern schon optimiert, und nur so dann natürlich auch wieder ausgelesen werden kann, oder?

Ich sehe hier also drei Bugs, die meiner Meinung nach behoben werden müssten:

Fehlerhafte Grafische Darstellung der Hervorhebungen (CSS), einfach, stark
Ignorierung jeglicher Zeilenumbrüche (Absätze) in Zitaten (Parser)
Speicherung des Geparsten Postings in der Datenbank, anstatt der Rohform (DB-Konzept)

Zumindest den ersten Bug kann ich ja mit meinem Userstyle lösen, beim Rest müsste jemand mit entsprechenden Rechten mal ans Forensystem Hand anlegen 🙂

Pierre

Ob einfache Hervorhebung jetzt kursiv und/oder fett ist hat keinen bestimmten Grund. Kann ich gerne auf kursiv ändern.
Da gibt es tatsächlich einen Bug im Zusammenhang mit Zeilenumbrüchen innerhalb von Zitaten (ich ahne da schlimmes; der Code hierzu ist ohnehin schon komplex). Natürlich ist der Fehler nicht mit Absicht drin; k.A. wie Du darauf kommst.
kannst Du ein Beispiel geben? Aktuell wird es genauso gemacht: Das Posting wird geparst und dann in die DB gespeichert, so dass es beim Anzeigen direkt ausgegeben werden kann. Beim Bearbeiten wird versucht dies wieder rückgängig zu machen. Das ist natürlich nicht immer eindeutig.

Dirk

Pierre schrieb* Ob einfache Hervorhebung jetzt kursiv und/oder fett ist hat keinen bestimmten Grund.

Na ja, irgendwas musst du dir dabei ja gedacht haben, einfache Hervorhebung fett und kursiv, und starke Hervorhebung nur fett zu machen 🙂

Pierre schriebder Code hierzu ist ohnehin schon komplex

Auslagern, auslagern, auslagern 🙂 Alles rausschmeißen und in eigene Klassen/Funktionen schreiben, was mehr als ein mal verwendet wird, und diese dann einbinden 🙂 Und immer dafür sorgen, dass alles ausschließlich über feste Schnittstellen Verbunden ist. So kann man Einzelteile nämlich wunderbar ändern, ohne, dass man das gesamte Beeinflusst – Aber da werde ich dir nix neues erzählen.

Pierre schriebNatürlich ist der Fehler nicht mit Absicht drin; k.A. wie Du darauf kommst.

Weil es mal anders war 🙂

Pierre schrieb[Formatierung beim Bearbeiten] kannst Du ein Beispiel geben?

Aber gern, dazu speichere ich den Artikel jetzt, und bearbeite ihn gleich wieder, und für einen Vorher- und einen Nachher-Screenshot ein.

Vorher:

http://img682.imageshack.us/img682/7083/tbefore.png

Hinterher:

http://img291.imageshack.us/img291/3729/tafter.png

Bei längeren, und auch komplexeren Postings (code-Tags, merhere Zitate, etc.) ist es eine Pest, das zu bearbeiten.

PMedia

Wäre es nicht klüger (hab ich auch mal für ein System gemacht), beide Kopien zu speichern?

Natürlich wäre eine 1:1-Konvertierung Implementierungstechnisch toller, aber so könnte man bedenkfrei Cleanups machen... wär eine imho einfache Problemlösung.

//edit

Kopien == {source, geparst}

Dirk

PMedia schriebNatürlich wäre eine 1:1-Konvertierung Implementierungstechnisch toller, aber so könnte man bedenkfrei Cleanups machen... wär eine imho einfache Problemlösung.

Ich bin sehr Fan davon, den Kram zwar Sanitized, aber ansonsten so roh wie möglich in der Datenbank abzulegen. Das Reinigen kann man beim Auslesen machen. Und danach muss man ja sowieso nur noch den Cache-Hash mit dem DB-Hash vergleichen.

PMedia

Dirk Sohler schrieb
PMedia schriebNatürlich wäre eine 1:1-Konvertierung Implementierungstechnisch toller, aber so könnte man bedenkfrei Cleanups machen... wär eine imho einfache Problemlösung.
Ich bin sehr Fan davon, den Kram zwar Sanitized, aber ansonsten so roh wie möglich in der Datenbank abzulegen. Das Reinigen kann man beim Auslesen machen. Und danach muss man ja sowieso nur noch den Cache-Hash mit dem DB-Hash vergleichen.

Ich bin da nicht so wirklich Fan von.
Mit einem Update der Codes zerstörst du zig alte Postings.
Abgesehen davon, warum etwas sich nicht änderndes dauernd neu parsen? Klar, Cache... aber das läuft ja dann aufs selbe hinaus was ich sagte.

Dirk

PMedia schriebwarum etwas sich nicht änderndes dauernd neu parsen?

Es wird nur neu geparst, wenn man es ändert, ansonsten kommt es aus dem Cache. Oder man gibt es eben einfach so zurück, wie es eingegeben wurde. Ob da jetzt ein Zeilenumbruch mehr oder weniger drin ist, ist HTML auch egal 🙂

PMedia

Dirk Sohler schrieb
PMedia schriebwarum etwas sich nicht änderndes dauernd neu parsen?
Es wird nur neu geparst, wenn man es ändert, ansonsten kommt es aus dem Cache. Oder man gibt es eben einfach so zurück, wie es eingegeben wurde. Ob da jetzt ein Zeilenumbruch mehr oder weniger drin ist, ist HTML auch egal 🙂

Zeilenumbrüche kann man sowieso ganz fix aus HTML rausfiltern... (wieso schrieb ich eben Zeilenausbrüche? o.O)

Ja aber so ist es doch effektiv so wie ich gesagt hab? Ein Cache stellt ja auch nur einen Speicher dar, der das geparste dann eben halt aufnimmt.
Wäre imho stark äquivalent dazu, würde man es einfach nebeneinander in die DB packen. Mag gegen Normalformen verstoßen, da die Daten ja errechnet werden können. Aber funktioniert dafür trotzdem gut ._.

Dirk

PMedia schriebWäre imho stark äquivalent dazu, würde man es einfach nebeneinander in die DB packen.

Auslesen aus der DB dauert länger als das Ausliefern eine HTML-Datei. Daher ja der von der DB gelöste Cache 🙂

PMedia

Dirk Sohler schrieb
PMedia schriebWäre imho stark äquivalent dazu, würde man es einfach nebeneinander in die DB packen.
Auslesen aus der DB dauert länger als das Ausliefern eine HTML-Datei. Daher ja der von der DB gelöste Cache 🙂

Mir war mal so, als ob Datenbanken auch einen RAM-Puffer hätten... falls nicht wär das wohl ne Marktlücke und würde Datenbanken zu reinen Suchmaschienen reduzieren, oder irre ich mich da?

Dirk

PMedia schriebMir war mal so, als ob Datenbanken auch einen RAM-Puffer hätten...

Ausreichend RAM Vorausgesetzt, wäre das durchaus was sinnvolles 🙂

The_Muh

Pierre schrieb

kannst Du ein Beispiel geben? Aktuell wird es genauso gemacht: Das Posting wird geparst und dann in die DB gespeichert, so dass es beim Anzeigen direkt ausgegeben werden kann. Beim Bearbeiten wird versucht dies wieder rückgängig zu machen. Das ist natürlich nicht immer eindeutig.

Speicher den ungeparsten und den Geparsten Text ab. Der ungeparste wird beim Editieren aufgerufen, eventuell auch beim zitieren mitgegeben. Das kostet zwar speicherplatz, is aber schneller (und imho sauberer) als rückwärts zu parsen.