Re: Having a problem with XML auto-escaping HTML (even CDATA)
Interesting. I would guess that XmlText and XmlCData are pretty much synonymous. Might change the way it outputs when you use ToString() to stuff it back into the database, but either way, with the cdata markup or with escaped html, it's exactly the same data / string, so there's no functional difference between them. (Hence the reason why tutorials generally don't make mention of the XmlCData variable.) Anyway, glad you found the answer you were looking for. -- s. isaac dealey ^ new epoch isn't it time for a change? ph: 503.236.3691 http://onTap.riaforge.org/blog ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;160198600;22374440;w Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:299045 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Having a problem with XML auto-escaping HTML (even CDATA)
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 manually either, saving to node.XmlCData instead of node.XmlText will handle it all. http://livedocs.adobe.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ColdFusion_Documentation&file=1512.htm >> #trim(theQuery'sXMLValue)# >> >> > > >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: > > <= this is both a node and an element (tag) >stuff in textarea <= this is a text node ><= this is another element node >anchor text<= this is another text node >bold <= this is part of the same text node > <= again, still the same text node > <= closing the 'a' element node ><= closing the 'textarea' element node > >Now when you create your xml packet originally using this syntax > > > $4,000 > > > > > >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 >"wow" -- 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: > > <= good > > <= 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. :) > >ike > >-- >s. isaac dealey ^ new epoch > isn't it time for a change? > ph: 503.236.3691 > >http://onTap.riaforge.org/blog ~| Adobe
Re: Having a problem with XML auto-escaping HTML (even CDATA)
> #trim(theQuery'sXMLValue)# > > 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: <= this is both a node and an element (tag) stuff in textarea <= this is a text node <= this is another element node anchor text<= this is another text node bold <= this is part of the same text node <= again, still the same text node <= closing the 'a' element node <= closing the 'textarea' element node Now when you create your xml packet originally using this syntax $4,000 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 "wow" -- 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: <= good <= 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. :) ike -- s. isaac dealey ^ new epoch isn't it time for a change? ph: 503.236.3691 http://onTap.riaforge.org/blog ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;160198600;22374440;w Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:299037 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Having a problem with XML auto-escaping HTML (even CDATA)
>> > >Shouldn't that be
RE: Having a problem with XML auto-escaping HTML (even CDATA)
> > > > $4,000 > What a deal! blahJust > Wow!]]> > > > > > INSERT INTO someTable(blah) > VALUES() > Shouldn't that be