To me the difference is a quick solution that works for the moment. I totally agree the JS solution was ugly (and it stopped working as soon as my string got large).
All solutions suggested mean I have to spend many hours figuring out how to implement it in my situation. As said, I have a tree of objects with all kinds of "values" (dates, strings, strings containing HTML) and actually only in the JXTemplate I parse it to an XML structure. All suggestions done so far, either build a flowscript function or a pipeline. Elegant solutions, but it would mean I have to traverse my tree of objects, either figuring out which one is appropriate for parsing or build a class that only acts on appropriate objects. And that takes a long time (which, of course I don't have). BTW. Reading up on your link, I suppose I've used it in one of the rare cases where it is more or less accepted: I only use it to display text that is previously entered using HTMLarea and therefore contains HTML tags. As long as I don't run into problems right now, I'll use the "disable-output-escaping" hack for now. But I'll store all other suggestions for future reference. Thanks. Bye, Helma > -----Original Message----- > From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 17 November, 2004 00:08 > To: [EMAIL PROTECTED] > Subject: Re: Converting <tag> to <tag>, how? > > > On 16.11.2004 23:14, [EMAIL PROTECTED] wrote: > > > Ha! That's it! Thanks so much. > > > > All the other suggestions assume one large string of text, but I > > actually have a kind of DOM tree containing text, some of > which could > > be HTML. > > What's the difference? > > To be honest, the client-side JS solution looks really ugly. > And I personally do not like disable-output-escaping: > http://www.dpawson.co.uk/xsl/sect2/N2215.html. It's always somewhat > hacky. And it does not work in a pipeline, i.e. you can not > post-process > the tags in the string in a later XSLT as disable-output-escaping is > just a hint for the serializer to not escape this string. I > will never > recommend it or use it if there are other solutions possible. > > Joerg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
