It's not "how it happens to work" that bothers me. I think it questionable (ie: worthy of question), but it doesn't bother me.
What *does* bother me is the almost religious defence of "how it is" that people are undertaking. "Religious" in both the intensity of "discussion" and lack of application of sense or logic. You're reverse-engineering an explanation to fit the situation. But anyway. I'll agree to continue to be a CF agnostic... You can meet with the others in church ;-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kotek Sent: Thursday, 28 October 2004 8:54 a.m. To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Calling CFC method as URL always returns WDDX? - why it bites You can give reasons all day for why you think it should be different man. I'm just telling you how it is. If it bothers you that much go submit an enhancement request for it. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Adam Cameron > Sent: Wednesday, October 27, 2004 3:43 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Calling CFC method as URL always returns WDDX? - why > it bites > > 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] ---------------------------------------------------------- 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]
