RE: Having a problem with XML auto-escaping HTML (even CDATA)
cfsavecontent variable=myXML ?xml version=1.0 encoding=UTF-8? car price$4,000/price adbody!CDATA[[Wow bWhat a deal!/b ulliblah/li/ulJust Wow!]]/adbody /car /cfsavecontent cfquery... INSERT INTO someTable(blah) VALUES(cfqueryparam cfsqltype=cf_sql_varchar value=#myXML#) /cfquery Shouldn't that be ![CDATA[ instead of !CDATA[[ ?? Paul ~| 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:299013 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Having a problem with XML auto-escaping HTML (even CDATA)
cfsavecontent variable=myXML Shouldn't that be ![CDATA[ instead of !CDATA[[ ?? Paul Oops, that was my mistake. It's set correctly, I was just in a hurry re-typing that. It is ![CDATA[ :) ~| 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:299015 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Having a problem with XML auto-escaping HTML (even CDATA)
Hello! This is my first run at XML and it seems to be working well, aside from this particular problem. We have a SWF file that references an XML doc stored in a table in one of our databases. The SWF pulls everything just fine. However, when I'm setting new variables and re-updating the XML, no matter what, it automatically escapes all HTML. For example, here is a similar example of what the XML looks like when it goes into the database the first time: cfsavecontent variable=myXML ?xml version=1.0 encoding=UTF-8? car price$4,000/price adbody!CDATA[[Wow bWhat a deal!/b ulliblah/li/ulJust Wow!]]/adbody /car /cfsavecontent cfquery... INSERT INTO someTable(blah) VALUES(cfqueryparam cfsqltype=cf_sql_varchar value=#myXML#) /cfquery Now when I initially build the XML like that, it will pass in any and all html I give it. It inserts like it should. But on subsequent updates, I update the values like such: cfqueryselect xml value from table/cfquery cfxml variable=xmlVar#trim(theQuery'sXMLValue)#/cfxml cfset xmlVar = xmlParse(trim(xmlVar)) HERE IS THE PROBLEM cfset xmlVar.car.adbody.XmlText = #New Value From Form Goes Here# After all of the cfsets, I do an update on the table and submit #xmlVar# again. Everything else works and saves and does what it should. But for some reason, I can confirm that: 1) The new form value holds unescaped html 2) Even referencing xmlVar.car.adbody.XmlText shows that variable holds the unescaped html And yet, when I look up that row in MySQL, it shows ESCAPED html. I dug a little further and found that: xmlVar.car.adbody.XmlText = UNESCAPED HTML (correct) xmlVar itself = ESCAPED HTML (incorrect) So for some reason when I'm setting a value in the XML, it auto-escapes the HTML. Is there a better way to set XML variables? Building the tree the same way it's done on creation isn't as easy because not all of the info comes across in a single form submission. This way works fine, except when it comes to HTML. I've searched and searched and have not yet found a function that will help me keep it intact. CDATA lets it store and display correctly, but even the CDATA html gets escaped rendering it useless =/ ~| 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:299011 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)
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;bgt;bold = this is part of the same text node lt;/bgt; = 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 car price$4,000/price adbody ![CDATA[ Wow bWhat a deal!/b ulliblah/li/ulJust Wow! ]] /adbody /car 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 bwow/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. :) 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:
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 ![CDATA[ and ]] 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_Documentationfile=1512.htm 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;bgt;bold = this is part of the same text node lt;/bgt; = 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 car price$4,000/price adbody ![CDATA[ Wow bWhat a deal!/b ulliblah/li/ulJust Wow! ]] /adbody /car 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 bwow/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
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
