Re: Having a problem with XML auto-escaping HTML (even CDATA)

2008-02-14 Thread s. isaac dealey
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)

2008-02-14 Thread Chris Johnson
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)

2008-02-14 Thread s. isaac dealey
> #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)

2008-02-14 Thread Chris Johnson
>> 
>
>Shouldn't that be 

RE: Having a problem with XML auto-escaping HTML (even CDATA)

2008-02-14 Thread Paul Vernon
> 
> 
> 
>   $4,000
>   What a deal! blahJust
> Wow!]]>
> 
> 
> 
> 
> INSERT INTO someTable(blah)
> VALUES()
> 

Shouldn't that be