Erlauben von bestimmten HTML-Entities in Feldern

[marius_haechler]

Wir möchten unseren Autoren erlauben bestimmte HTML-Entites in einem Textfeld einzufügen.

Da wären zum Beispiel ­ um Zeilenumbrüche zu definieren oder   um Zeilenumbrüche zu verhindern.

Alle anderen HTML-Entities sollten aber weiterhin escaped werden.

Aktuell schreiben wir in etwas so etwas:

st_text.convert2.replaceAll("­", "­")

Das funktioniert grundsätzlich muss aber bei jedem Feld ergänzt werden wo die Ausgabe dies enthalten soll.

Gibt es eine besseren Möglichkeit dies global zu lösen?

[chwal]

Hallo Marius,

kannst du uns genauer erläutern wie euer Anwendungsfall aussieht?

Was ist mit einer Checkbox neben der Eingabekomponente für das Umbrechen / Nicht umbrechen, die in der Ausgabe entsprechendes word-wrap (CSS) steuert?

Viele Grüße
Sebastian

[mbergmann]

Hallo Marius,

aus der Erfahrung heraus würde ich davon abraten, die Eingabe von HTML (-Elementen) zu unterstützen, insbesondere vor dem Hintergrund, dass Inhalte von EKs eigentlich "Ausgabe-formatneutral" sein sollten. Sonst fängt man irgendwann an, Dinge hin- und herzukonvertieren. Außerdem entsteht dann auch immer eine gewisse Unsicherheit "welche sind jetzt unterstützt, welche nicht" usw.

Vorschläge für Alternativen:

Nutzung von INPUT_DOM und Nutzung von Format- oder ggf. Linkvorlagen - wäre aber natürlich ein gewisser Migrationsaufwand.

Wenn es bei reinen Textfeldern bleiben soll und es wirklich nur ein paar Sonderfälle sind, funktioniert auch ggf. die Einführung einer eigenen "Spezialnotation" ganz gut, z.B. eine Syntax mit {...} oder bei speziellen Zeichen auch eine "Word-artige" Ersetzung, z.B. (c) => © Was da unterstützt wird, kann man auch über diverse Wege dem Redakteur direkt im Formular mitgeben. Von einfachen CMS_LABELs (die man natürlich dann immer in jedem Formular nachziehen müsste) bis hin zu einer Art pflegbaren "Ersetzungstabelle" in Form einer Datenquelle, die man sich über einen FS_BUTTON anzeigen lassen kann.

Das hat dann aber natürlich auch die Tendenz, im Laufe der Zeit immer weiter "zu wachsen", so dass man irgendwann dann so nahe an den Formatierungsmöglichkeiten eines INPUT_DOM ist, dass man von Anfang an einen hätte nehmen sollen...

Da gibt es meiner Meinung nach nicht unbedingt die perfekte Lösung. Es kommt dabei darauf an,

• wie viele solcher "Features" gewünscht sind
• an wievielen Stellen das gewollt ist (geht es nur um ein paar Überschriften oder um "alles")
• ob diese "Spezialfeatures" tendenziell im Laufe der Zeit eher mehr werden
• ob sie überall dieselben sein sollen oder ob es eine Steuerungs-/Konfigurationsmöglichkeit geben soll, was für welche Felder unterstützt wird
• ob es eine Art zentrale "administrative Pflegemöglichkeit" geben soll, in der die Ersetzungen gepflegt werden sollen (hängt letztlich auch von den anderen Fragen ab).

Die Konvertierung selbst kann man dann über ein entsprechendes Rendertemplate erledigen.

Viele Grüße

Michael

[mikula]

Hallo Marius,

ich kann mich Michael nur anschließen, tatsächlich würde ich es sogar komplett vermeiden wollen, schon alleine wenn ich daran denke, dass man evtl einen anderen Kanal mit dem gleichen Text bestücken möchte und dann sind in Print-texten auf einmal html entities.

Benötigst Du noch weitere Hilfe oder hat Dir die Antwort von Michael bereits geholfen? In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Martin