Ike, thank you :)

Turns out the problem was much simpler.  Although to be fair to myself, I have 
to say that most of the online documentation I've found completely ignores the 
presence of a XmlCData element and only references the XmlText element.

Turns out that you don't have to add/replace the <![CDATA[ and ]]> manually 
either, saving to node.XmlCData instead of node.XmlText will handle it all.


>> <cfxml variable="xmlVar">#trim(theQuery'sXMLValue)#</cfxml>
>> <cfset xmlVar = xmlParse(trim(xmlVar))>
>You're using one or the other of these, not both together, right? 
>Other than that, it sounds less like there's something going wrong with
>the XML than there just being some confusion about how XML works -- or
>at least how it works in ColdFusion. 
>Some basics: 
><textarea>         <= this is both a node and an element (tag) 
>stuff in textarea  <= this is a text node 
><a href="blah">    <= this is another element node 
>anchor text        <= this is another text node 
>&lt;b&gt;bold      <= this is part of the same text node 
>&lt;/b&gt;         <= again, still the same text node 
></a>               <= closing the 'a' element node 
></textarea>        <= closing the 'textarea' element node 
>Now when you create your xml packet originally using this syntax 
>  <price>$4,000</price>
>  <adbody>
>    <![CDATA[ 
>      Wow <b>What a deal!</b> 
>      <ul><li>blah</li></ul>Just Wow!
>    ]]>
>  </adbody>
>You have your document root element (car) with two child elements (price
>and adbody) and each child element contains one text node, and here's
>where I think you're getting tripped up. How that text node in the CDATA
>is formatted isn't really important -- what's important is that it *is*
>a text node. It may be formatted with CDATA - it may be formatted by
>escaping the HTML tags - but either way, it's a single text node. And
>actually once you've put it into the adbody element as a text node, you
>don't really have any control over how it will be formatted when it's
>displayed by a given XML engine and most of them will use character
>entities (escaping) instead of CDATA to represent the string. The reason
>you see the CDATA after your initial creation I'm guessing is because
>you're not parsing the XML prior to the initial insert, you're just
>building it as a flat text string and inserting it, so the XML engine
>isn't getting its hands on it. 
>Now, moving on... When you look at it in MySQL you're seeing escaped
>HTML with character entities -- so it's showing you that the content of
>the adbody element is still a string - good, that's the way you want it.
>Then when you later take the XML packet out of MySQL there are several
>different ways you can get at its content within CF and the results will
>look different of course dependant upon how you choose to display it.
>What you really want is just to get your string back out so that it can
>be used in your HTML display. So your use of "xmlVar.car.adbody.XmlText"
>as a variable name to get that string is perfect -- once the XML has
>been parsed, that variable will contain a string with unescaped HTML,
>which is what you want. 
>The only time you won't see the unescaped HTML is when you're viewing
>that text node as a text node within the larger XML packet, for example,
>if you use cfdump to display the content of your xmlVar variable. When
>you dump it like that you're asking the server to show you the structure
>of the XML, in which case, what it's showing you is that you have this
>text node in your adbody element that contains these strings like
>"<b>wow</b>" -- it doesn't care what that string is or what you do with
>it after you get it out, its only responsibility is to show you that the
>string contains those characters. So that's also good. 
>Lastly, where you're updating the XML packet with a new html adbody
>should also be fine as well, as long as you're not using HTMLEditFormat
>() on the string before inserting it into the packet. For example: 
><cfset xmlVar.car.adbody.XmlText = form.addbody> <= good 
><cfset xmlVar.car.adbody.XmlText = HTMLEditFormat(form.adbody)> <= bad 
>Remember that the only job of the XML packet is to store your string in
>that text node in the adbody element, so when you set the XmlText
>variable this way, ColdFusion already knows that form.adbody is a string
>and it will just store that string in the XmlText exactly as it is so
>that when you later parse the packet and get it back out, you'll have
>exactly the same string coming out, including all the unmolested HTML.
>If you do any kind of editing to the HTML before you set it, then that
>will change the string before being stored and the value you get back
>will be whatever you've changed it to. So if you HTMLEditFormat the
>value before you store it, what you'll get out on the back end after you
>parse the XML later will be escaped HTML. 
>Anyway, I hope I've been at least sem-coherent here and that this
>information is somewhat useful to you. :) 
>s. isaac dealey  ^  new epoch
> isn't it time for a change? 
>     ph: 503.236.3691

Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to 
Get the Free Trial

Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm

Reply via email to