[TYPO3-german] RTE nervt - Paragraph, Schachtelung, Absatz-Tags

Mon Jul 10 21:48:43 CEST 2006

Peter Niederlag wrote:
> Hallo,
> 
> Uschi Renziehausen schrieb:
>> Hi Carla,
> [...]
>> Solange keiner den Moloch HTMLparser und parseFunc anfasst, um die
>> beiden auf einheitliche Füße zu stellen und es wirklich funktionierende
>> und aufeinander abgestimmte Defaults für lib.parseFunc und
>> lib.parseFuncRTE sowie für die Transformation zwischen RTE und DB,
>> beißen auch diejenigen bisweilen frustriert in die Tastatur, die wissen,
>> wie Elemente RICHTIG verschachtelt werden und durchaus CSS können.
>>
>> Ich schreibe das in der Stimmung, die so entstehen kann, wenn frau zwei
>> Wochen lang Zeile für Zeile t3lib_htmlparser und t3lib_htmlparser_proc
>> debugged, um rauszufinden, an welcher Stelle denn eigentlich mein
>> VALIDER Code zunichte gemacht wird!
> [...]
>> Variante 1 ist mehr oder weniger ausgeschlossen, weil zumindest im
>> HTMLparser div und p hartkodiert gleichbehandelt werden und die strikte
>> Devise entweder/oder gilt. Stünde die Konfigurationsoptionen von
>> parseFunc auch für das BE zur Verfügung, gäbe es Wege aus der Krise und
>> als positiven Nebeneffekt gleich auch noch eine Entschlackung des
>> Vokabulars.
> 
> Sehr schöne Worte. :->
> 
> Das Problem ist nur, dass es wahrscheinlich keine ganz so triviale
> Aufgabe ist. Und wenn dann auch noch die Devise "rückwärtskompatibel"
> gilt: IMO unmöglich.
> 
> In der 5.0 oder einer anderen Version, die nicht mehr von dem
> Damoklesschwert "Rückwärtskompatibilität" bedroht ist, wird genau das
> sicherlich eine der wichtigen Aufgaben sein.
> 

Ich in meinem jugendlichen Leichtsinn sehe das gar nicht sooo 
pessimistisch, und ich möchte auch keinesfalls bis Version 5 warten, 
jedenfalls nicht mit ein paar kleinen, aber entscheidenden und vor allem 
notwendigen Verbesserungen, ich denke da eher Richtung 
Vorwärtskompatibilität.

Wenn ich das richtig kapiert habe, kann man ja so einen hybriden 
Metamode definieren, nennen wir den mal spasseshalber ts_realhtml. Der 
darf alles genauso machen wie ts_css mit Ausnahme dessen was passiert, 
wenn css_transform an der Reihe ist.

Folgendes würde ich anpeilen:

1) Was als Paragraph-Tag gilt, muss in den Händen des Site developers 
liegen. Damit wäre P=DIV schon fast aus der Welt. Ich nenne das Kind 
jetzt mal paragraphTags, Wert ist eine Kommaliste, also z.B.

RTE.default.proc.paragraphTags = p, para, par

TSconfig-Doku unter ->PROC
Here you can define all elements you would like to be regarded as 
paragraphs by the parser. Everything you define here will be remapped to 
 or to whatever you have defined under 
RTE.default.proc.remapParagraphTag when first stored into the database.

2) Man könnte remapPragraphTag einen neuen Wert verpassen, e.g. 0, und 
wenn der gesetzt ist, dann wird eben nichts umgewandelt. Muss man überlegen.

3) Ob in der Datenbank gespeichert wird, ist Sache des Site developers.
RTE.default.proc.storeParagraphTags =0/1 (also boolean)
Wenn 1, dann werden die -Tags in der DB gespeichert und zwar bitte 
mit chr(10) hinter , damit der Code lesbar bleibt.

4) Welche Blocks rekursiv geparsed werden sollen, muss ebenfalls in den 
Händen des Site developers liegen. Im Moment sind da nur Vorkehrungen 
für <blockquote> und ein paar andere Elemente getroffen (ol,ul,table):

RTE.default.proc.externalBlocks.tagname.callRecursive

Auf dem Weg DB=>RTE muss genau dasselbe passieren wie auf dem Weg 
DB=>FE, schließlich geht es beide Male darum, aus dem, was in der DB 
steht, wieder RTE- respektive FE-fähiges HTML zu machen.
Und für den Weg RTE=>DB, da schaumerma.

5) In jedem Fall muss abgesichert sein, dass keine leeren 
Inline-Elemente stehen bleiben, also sowas hier: . Das darf absolut kaputtautomatisch 
passieren.

6) GANZ WICHTIG: Diese hsc-Frage! So wie das jetzt ist, treibt das jeden 
in den Wahnsinn. ERST gucken, ob bewusst irgendwelche Entities 
eingegeben wurde, diese irgendwie schützen (und sei es durch Umwandlung 
in einen fiesen MD5-String) und DANN alles htmlSpecialChars 0/1/2/-1 und 
dann MD5-Strings zurückverwandeln in Entitities.

Tja, und wenn dann die Power noch reicht, könnte man ja auch noch ein 
paar Goodies einbauen, die es vielleicht ermöglichen würden, aus Word 
und Konsorten gepasteten Inhalt so zu transformieren, dass nicht gleich 
alle Formatierungen gnadenlos gehimmelt werden, so in Abhängigkeit von 
Attributen und deren Werten :). Dann könnte man z.B. aus dem HTML-Code 
auch DOC BOOK machen oder umgekehrt und Doku damit schreiben und hach, 
unbegrenzte Möglichkeiten.

Beim Betrachten von tslib_cObj->parseFunc ist mir aufgefallen, dass 
ohnehin ein Großteil der Transformationen ohnehin mittels 
t3lib_parseHTML ausgeführt werden. Wenn man das vielleicht ein wenig 
konsequenter durchführen könnte ... MUSS doch gehen, und was nicht 
passt, wird halt passend gemacht ;-)

> Vielleicht hast Du ja Lust deinen Frust in ein paar Idee/Ansätze
> umzuformulieren und irgendwo festzuhalten? Wie könnte sowas
> funktionieren? Was sollte gewährleistet sein? Wie sollte es
> konfigurierbar sein? ... und ab als mail oder ins wiki damit.
> 

Ich musste das erstmal jetzt hier so hinschreiben, damit es raus ist. 
Ich habe mich übrigens bereits im Wiki zum Thema RTE. Ich wäre dir 
dankbar, wenn du dir das incl. der zugehörigen 'Philosophie' mal 
durchläsest und deine Meinung mitteilst.

Irgendwie habe ich zu lange im eigenen Saft geschmort und abgesehen 
davon weiss ich meist nicht, in welcher News group ich was posten 
sollte. Ich lese derzeit dev, hci, extension-coordination, typo3.org, 
rte, content-rendering, tempavoila, documentation und ein bisschen 
english und german und alles durcheinander, um halbwegs den Durchblick 
zu kriegen. Die Dinge hängen alle so eeekelhaft zusammen.

> Für mich ist die große Gretechenfrage, ob der Ansatz so wenig Markup wie
> möglich zu speichern (bspw. chr(10) statt <p>|</p>) nicht auch einfach
> fallengelassen werden sollte. Das würde nämlich schonmal wieder einiges
> an Arbeit/Komplexität rausnehmen.
> 
> Das wäre doch schonmal Klasse!
> 

Hm, also ich habe mich das so ähnlich auch gefragt, und ich glaube, so 
als echte Zukunftsmusik würde ich es betrachten, wenn die Schnipsel in 
der DB valides XML sind, und dann auf dem Weg zur Textarea transformiert 
  wird, wenn der RTE nicht zur Verfügung steht. Diese Transformation 
könnte man dann auch bleiben lassen, wenn man sie nicht braucht. Dieser 
Schritt allerdings muesste, denke ich, wirklich bis 5 warten.

Liebe Grüße, Uschi
> Gruß,
> Peter