Sorry, but that's rubbish.
Consider type casting in other languages (this is pseudocode):
Float f = 1.234;
String sF = f.toString(); // sF holds 1.234
Int i = -4;
String sI = i.toString; // sI holds -4
String s = "Hello World";
String ss = s.toString; // sS holds Hello World
Struct st = structNew();
String sSt = st.toString(); // sSt holds result of the internal
toString() method of the language's struct class, which might perform a
toWDDX() transformation (the equiv of <cfwddx action="cf2wddx">.
MyClass o = new MyClass;
String sO = o.toString; // sO holds the result of some bespoke
toString() method that does whatever the developer deems appropriate for
a toString(). Maybe a pipe-separated list. Maybe CSV format. Maybe
some proprietary XML that has far less overhead than WDDX. But the crus
is: whatever is most prudent @ the time.
Now. CF works out that it's been asked to do some processing, and any
results of which much end up being a string ("it must be type cast as a
string"). So what it *should* be doing to fulfil this requirement is to
do an implicit toString() on any method returns called via HTTP. It
should *not* be doing an implicit toWDDX(). The toString() methods that
arrays, structs, queries and such like use might decided that their
toString() might use WDDX to convert their complex data to a coherent
string, but that's not to say *everything* has to do it.
You're losing sight of the fact the object of the exercise is to convert
it to a string, not convert it to WDDX. An HTTP repsonse is character
data, not wddx data. Nor, even - as someone is about to suggest - XML
data or any sort of mark-up data @ all. Formatted character data is a
"nice to have", but it's not actually a requirement, so it shouldn't be
ENFORCED as a requirement.
Adam Cameron
Senior Application Developer
Straker Interactive
E: [EMAIL PROTECTED]
T: +64 9 3095252
F: +64 9 3092797
W: www.straker.co.nz
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Kotek
Sent: Thursday, 28 October 2004 4:10 a.m.
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Calling CFC method as URL always returns WDDX? -
why it bites
That's fine if the CFC method is returning a string, you could argue
"why not just output the string to the HTTP buffer?" But what if the
method is returning a query? An array? A structure? CF *can't* just
output it to the HTTP buffer...*unless* it encodes it to WDDX first!
Which is why you're seeing what you're seeing...CF doesn't make
distinctions on the type of the data the method is returning, it encodes
all types as WDDX. That's the only consistent way it could be done.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of stylo~
> Sent: Wednesday, October 27, 2004 3:42 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Calling CFC method as URL always returns WDDX? -
why
> it bites
>
>
> 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."
>
----------------------------------------------------------
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]
----------------------------------------------------------
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]
