BBCode -> XML
Andi
- xml
0 Thomas J.S.0 Steffen0 Thomas J.S.0 Steffen0 Thomas J.S.0 Steffen
Hi,
ich habe folgendes Problem. Ich schreibe gerade an eine Webanwendung (JSP) die diverse Eingaben in XMLs abspeichert.
Jetzt möchte ich gerne BBCode ermöglichen. Einen entsprechenden Parser habe ich bereits. Allerdings habe ich folgendes Problem. Wenn ich die Texteingabe durch den BB- Parser jage wird ja so etwas: [b]fett[/b] zu <b>fett</b>.
Das wird dann in der XML Datei allerdings als <b>fett</b> gespeichert, was ja auch korrekt ist. Nur wenn ich das Ganze dann mit XSLT darstellen will, kriege ich auch <b>fett</b> angezeigt und nicht "fett" in fetter Schriftart.
Ich habe bereits ein Workaround für überschriften geschrieben, das macht folgendes: Es sucht nach <h> tags und parsed den text danach als überschrift, falls der <h> tag wieder geschlossen wird. In der XML wird dann ein Text "Text <h>Überschrift</h> mehr Text so gespeichert:
<XMLText>
<text>Text </text>
<h>Überschrift</h>
<text> mehr Text</text>
</XMLText>
Nun kann man <h> tags über die XSLT- Datei als Überschrift darstellen. Das ganze ist aber ziemlich mühsam und ich wollte mal nachfragen ob jemand eine besser Lösung kennt. Ich hoffe ich habe genug Infos gegeben um mein Problem verständlich zu machen. Sonst fragt halt nochmal nach :)
Hallo,
Das wird dann in der XML Datei allerdings als <b>fett</b> gespeichert, was ja auch korrekt ist. Nur wenn ich das Ganze dann mit XSLT darstellen will, kriege ich auch <b>fett</b> angezeigt und nicht "fett" in fetter Schriftart.
<element>
<b>fett</b>
</element>
<xsl:value-of select="element" disable-output-escaping="yes" />
Grüße
Thomas
Allerdings vorausgesetzt,
der Parser unterstützt disable-output-escaping="yes" ;-)
Gruß
Hallo,
Allerdings vorausgesetzt,
der Parser unterstützt disable-output-escaping="yes" ;-)
In ordentlicher XSLT-Prozessor macht das. Man sollte eben nicht die im FF/Mozilla eingesetzte kastrierte Version von TransforMiiX nehmen.
Grüße
Thomas
Nun ja,
zumindest fuer XSLT2.0 Spec wird disable-output-escaping "verbannt" mit Verweis auf bad coding und character maps eingefuehrt.
Gruss, Steffen
Hallo,
zumindest fuer XSLT2.0 Spec wird disable-output-escaping "verbannt" mit Verweis auf bad coding und character maps eingefuehrt.
hm... du liest zu viel von Mozilla ;-) (?) "bad coding" ist _der_ hirnrissige Argument der Entwickler, warum der im Mozilla eingebaute XSLT-Proz. disable-output-escaping nicht unterstützt.
Es ist korrekt, dass es keine Anforderung war [1], dass ein XSLT-Proz. disable-output-escaping unterstützt, da dass dazu die Kontrolle über die Serialisierung notwendig ist[2]. Aber ich kenne keinen nennenswerten XSLT-Proz. der das nicht könnte.
Für XSLT 2 hast du "recht", dort ist "disable-output-escaping" mittlerweile als deprecated gekennzeichnet. Dennoch gibt es Anwendungsfälle, wo "disable-output-escaping" einfach die bessere/einfachere Lösung ist. Character Maps ist eine Lösung, wenn auch nicht immer die beste/einfachste ;-)
Grüße
Thomas
Hallo Thomas,
hm... du liest zu viel von Mozilla ;-) (?) "bad coding" ist _der_ hirnrissige Argument der Entwickler, warum der im Mozilla eingebaute XSLT-Proz. disable-output-escaping nicht unterstützt.
Nein, eigentlich hatte ich mich direkt auf die Spec Erwaehnung von XSLT2.0 bezogen
Will auch hier kein langes Sinngespraech vom Zaun brechen, aber man sieht so ab und zu, wie diese Moeglichkeit regelrecht missbraucht wird. So ist es mir schon des oefteren auf meinen Arbeitsschirm gekommen, dass diese Technik etwa dafuer verwendet wird, um schema restriktionen (z.B. keine Unterelemente erlaubt) zu umgehen. Da kann man sich schon an den kopf greifen, und fragen, warum man ueberhaupt XML nutzt. Und das Posting vom Ursprungsposter sieht mir nach einem aehnlichen Versuch aus.
Gruss, Steffen