Andi: BBCode -> XML

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 &lt;b&gt;fett&lt;/b&gt; 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 :)

  1. Hallo,

    Das wird dann in der XML Datei allerdings als &lt;b&gt;fett&lt;/b&gt; 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>
    &lt;b&gt;fett&lt;/b&gt;
    </element>

    <xsl:value-of select="element" disable-output-escaping="yes" />

    Grüße
    Thomas

    1. Allerdings vorausgesetzt,

      der Parser unterstützt disable-output-escaping="yes"  ;-)

      Gruß

      1. 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

        1. Nun ja,

          zumindest fuer XSLT2.0 Spec wird disable-output-escaping "verbannt" mit Verweis auf bad coding und character maps eingefuehrt.

          Gruss, Steffen

          1. 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.

            1. ist noch immer einer der Argumente von den Mozilla Entwickler (nur können sie nicht erklären, warum der "echte" TransforMiiX dies doch kann)
            2. dieses Argument bringen die Herren seit jeher auch gerne immer wieder mit der Bemerkung, dass die Serialisierung (Rechner)Leistung kostet. Was sicher ein berechtigtes Argument war. Damals, in 2001!

            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

            1. 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