Jimmy,
What I did was a work around because the, I agree, more elegant createobject did not work. If Json solves the problem for you then its no longer a problem. But I found much much easier and faster to write the calls via cfhttp than digg into the underlying Axis framework. Jorge ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jimmy Glass Sent: Monday, March 19, 2007 8:35 PM To: [email protected] Subject: RE: [CFCDEV] Consuming .Net WebServices & Parameter Datatypes Hi Jorge, No... I've not yet found the solution. The methodology that you have suggested seems to be inconvienent and cumbersome compared to the implied methodology of CreateObject("webservice", "http://";).Method(arguments). I would hope that a platform like ColdFusion would shield me from the implementation details of generating the soap message myself, which I believe is the promise of a WebService. Otherwise, I could come up with my own standard for this system using a much more lightweight serialization technique like JSON. Did you spend anytime trying to understand the underlying Axis framework? Jimmy G ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Iriso Sent: Monday, March 19, 2007 2:46 PM To: [email protected] Subject: RE: [CFCDEV] Consuming .Net WebServices & Parameter Datatypes Hello Jimmy, I don't know if you already worked a solution out, but anyway here it goes. I had problems in the past submitting complex objects to .net webservices and the work around was to generate the xml string (cfsavecontent) and send it directly using cfhttp. Include the soapaction and other header info as cfhttpparams (type header) and another cfhttparam (type body) with the xml string that you have built. I hope this helps. Jorge ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jimmy Glass Sent: Friday, March 16, 2007 4:28 PM To: [email protected] Subject: [CFCDEV] Consuming .Net WebServices & Parameter Datatypes Hi... I have been searching for information related to the consumption of .Net Web Services, specifically... how to handle complex data type conversions. Has anyone on this list had any experience consuming .Net Web Services with something more than key/value pair input parameters? We have a .Net Web Service that is looking for a collection (array) of Objects (CFCs, specifically... LineItems). What should the data type be for input parameters in the .Net Web Service? Any thoughts or suggestions would be greatly appreciated. Sincerely, Jimmy G ________________________________ From: Aaron DC <[EMAIL PROTECTED]> Sent: Friday, March 16, 2007 12:42 PM To: [email protected] Subject: Re: [CFCDEV] Generic getter Ok. My question was innocent - I have only been developing with CFCs for 5 months and learning and understanding what people are doing helps. When I was developing in VB 5 a while ago, the book I learnt the OO side of VB5 from (painful at best) had you creating setters and getters for every publically accessible element of the class. It became so repetitive and boring that I wrote a quick VB-based code generator to do it for me, just adding a list of field names to it as and when required. Typeless languages make that a simple proposition. I know from experience the less typing I have to do the less mistakes I make :) I am going to have to investigate these bean things soon, I tend to eat or brew the ones I come in to contact with. Thanks for your answer. Aaron Peter Bell wrote: > How about displaying it on screen? There ARE use cases for > #Product.display('Title')# #Product.display('Price')#, > #Product.display("ThumbnailImage')#, etc. You could compose the cf display > template within the bean, but you'd still be left with > #THIS.display('Title')# all over the template. > > Do agree that in the general case you want to provide as few getters and > setters as necessary. > > Best Wishes, > Peter > > > > On 3/16/07 3:06 PM, "Aaron DC" wrote: > > >> Can I ask why you are getting discrete elements of a CFC? What do you >> intend to do with the information once you have it? I don't mind my >> tables having 100 or more fields, btw. >> >> Thanks >> Aaron >> >> Phillip Senn wrote: >> >>> Here's a typical getter: >>> >>> >>> returntype="string"> >>> >>> >>> >>> My impression is that if a table has 100 fields, then there are going to >>> be 100 getters. >>> >>> Q: Is it possible to write a generic getter that uses perhaps an array >>> index or some other voodoo method instead of hard coding 100 getters? >>> >>> >>> returntype="any"> >>> >>> >>> >>> >>> >>> If the number 100 makes you uncomfortable, substitute the number 50, or >>> 25. Whatever number you're comfortable with. I know some people balk >>> at a table having 100 fields. >>> >>> >>> >> You are subscribed to cfcdev. To unsubscribe, please follow the instructions >> at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> >> > > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
