>If you call a CFC method from a browser, it always returns the result the same way: as an XML string which the browser can display. If you call a CFC method as a web service, it always returns the result the same way: as a SOAP value. If you call a CFC method from Flash Remoting, it always returns the result the same way: as a binary-encoded representation of the ActionScript format data. If you call a CFC method from another local CFC or a web page, it always returns the result the same way: as a CF value. It couldn't be more consistent than that - it returns data in a format consistent with the calling mechanism.
This is all very good reasoning (and paints a broader picture than I was thinking in terms of). However I would still argue the toss re web-browser calls. They expect string data and if it's already string data: leave it alone.
>If you call a CFC method from a browser and expect to get output, you'd better say output="yes" and write the output to the buffer - just like you would for a CFM page. Or have a displayXxx() method that calls xxx() and outputs the result.
The latter is a good suggestion.
>> DO YOU actually think it's *sensible* for a string return value to be wrapped in WDDX when you invoke it via HTTP?
>Yeah, makes perfect sense to me - even before I read the docs.
Well we're going to have to agree on varying mileage there.
>I think CF is being very consistent - I think you're the one asking for inconsistent behavior.
More than I was giving it credit for, yeah, fair enough.
Adam
