Thanks for your help on this issue, as I'm just re-writing an app and planned to use XMLHttpRequest and CFCs extensively. Right now I use dynamic scripts that call cfm pages and cfsavecontent is used to organize data, but it makes a mess of the backend. (If they were calling CFCs, I'd already have met this problem.)
> Seems I have to also delete the return type attribute from the function in > order to get rid of the XML and get my description only. Bizarre. Why is > that??? Surely that's a bug. >If you specify a return type, CF will reasonably assume you want to >return data regardless of whether you output anything. Surely more reasonable still would be to not send anything unless I specifically return something, no? What if there were no result to send based on the input? Why send an empty xml packet which I have to parse just to find out there is no result length inside? Looks like a bug. > So, I don't have a cfc I can use both internally from cfm pages, and > externally with my browser. >Well, if the CFC outputs stuff, then that's what it does. Similarly, >if it returns data, then that's what it does. I think the cfc shouldn't care how I use the data; it should simply return it and do so consistently, not assume that simply because going to a browser, I want the result wrapped in xml. (I understand there is the issue of how to send complex data, but, as I noted, I might want to use json format, which is perhaps a better format.) > I'm being forced to use XML formatting when quite often it is the worst > transport format. >You're not. If you make an HTTP request to a CFC, what comes back is >the HTTP response buffer *not* the returned value of the CFC. That's >because that's just the way HTTP works - if you request a CFM page, it >doesn't return a value, it writes to the HTTP response buffer. Sorry, I don't understand why you say that. The cfc is specifically wrapping the result in XML, right? And it doesn't need to do that, right? (You earlier suggested filing a bug request to change the behavior.) So, has nothing to do with how http works, but rather how MM designed CFCs to work. (If I call a cfm page from a browser, it doesn't wrap the result in xml, but a cfc does.) Net result if using XMLHttpRequest: 1) either I duplicate every cfc function I ever use so as to return the exact same data to cfm pages as to the browser (obviously bad) 2) I don't use cfcs (limiting), or make some workaround to call them via cfm pages (hackish and annoying) 3) I use xml which slows down the transport of the data, then the processing of the data clientside (poorer performance), though it does give a consistent method to work with. 4) figure out a solution. See below. I also tried posting to a cfc via XMLHttpRequest (instead of get) like a form, but still got xml back. Have to play more with that. Contrast: 1) Do no automatic wrapping of data in xml, and when I want xml from my cfc I will specifically format it like that, or, better still, toggle some attribute to send it that way (so it can be done easily and, most importantly, dynamically). I would not suggest changing the behavior for only strings, though. It's not a big deal right now, but as we use XMLHttpRequest more it might become one. (Footnote: the "XML" in "XMLHttpRequest" is irrelevant if anyone is wondering.) ****** Solution if you want only a string returned from a CFC, not XML: 1) Starting with Sean's suggestion of the outut attribute, I have found that using one of the 3 following works - along with cfoutput to the browser (can use if/then to reply to browser sending in a variable) - and no xml packet is tacked on: <cffunction name="test" access="remote" output="yes" returntype="any" > <cffunction name="test" access="remote" returntype="any" > <cffunction name="test" access="remote" > Problems: a) whitespace output has to be trimmed when received b) returntype data checking is lost because must use returntype "any" or none. (If a string returntype it adds the empty xml packet afterwards, which is a bug in my opinion as I didn't "return" anything.) 2) Or just give up and use the cfc normally, then regex the xml packet out. Still getting whitespace tacked on before the packet with output=no, not sure why. ---------------------------------------------------------- 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]
