>>I just tested this and if you have no <cfreturn> in your method and a
string return type, you should get a blank result, not a WDDX packet
(because there is no return value to encode).
I get an empty wddxpacket after the output. I tried:
<cffunction name="go" access="remote" output="true" returntype="string">
<cfoutput>#description#</cfoutput>
No return tag and I get (including whitespace when swapped into innerHTML of
a div):
[start]
description
<wddxPacket
version="1.0"><header><data><string></string></data></header></wddxPacket>[e
nd]
> I think the cfc shouldn't care how I use the data
> The cfc is specifically wrapping
> the result in XML, right?
>No. The HTTP request processor is doing that. It calls the CFC. It
encodes the returned value so it can write it to the HTTP response
buffer - because that's the only thing it has to work with.
What http processor? Coldfusion? There is an http header on it already; the
content itself doesn't need to be wrapped in xml. Whoever is doing it, and
wherever it is being done, it is Coldfusion choosing to wrap the cfc result
in this:
<wddxPacket
version="1.0"><header><data><string>description</string></data></header></wd
dxPacket>
which is not at all necessary http-wise, but something to do with how the
cfc interacts with browser calls. A cfc *could* output merely the text,
"description" with an http header to the browser rather than the above. A
cfm page doesn't wrap content in a wddx packet when answering over http.
Thus, the net effect is the same, but perhaps reworded as: "CF is
specifically wrapping CFC results in XML if called by a browser."
I'm not being belligerent here, just trying to figure out exactly what's
going on as I design an app with a clientside interacting remotely with the
server. There may be good design reasons for using wddx packets to return
content, or an internal necessity of CF, but certainly that's not "just the
way HTTP works."
Thanks for your help :-)
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]