Please RSVP before 12:00PM
Hi everyone, its CFUG time again.
This month Andrew Spaulding from Adobe will join us via Connect to show
us some real life AIR applications, as well as some of the new CS4 work
flows.
As usual we will have Food, Drinks and time for discussions.
I look forward to
Thanks for the offer guys. I'm finally getting somewhere, the documentation
lacks, but with a bit of guessing work I think I'll get their.
Cheers
On Fri, Nov 7, 2008 at 7:42 PM, michael sharman [EMAIL PROTECTED] wrote:
There are examples on the site, but not for webservices...only for an
XML
@Steve, Thanks for the response but I don't think you've understood me
correctly. I'll try to explain myself again.
Perhaps there is a CF web service guru out there that can help?
When building a web service, should the input arguments be a single
XML document (which defines the input
Further to the previous question: when you prepare the return data for
a function where access=remote would you build an XML document and
return it or would you just return the data in whatever datatype is
required e.g. string, numeric, array, struct etc. Then the underlying
CF builds it into an
All CF datatypes are converted to SOAP equivalents
So it says but i have seen time and time again issues with the soap
conversion and datatyping issues, especially with .NET
Using XML you know exactly what you are getting. Thats my reason.
-Original Message-
From:
Hi Matthew,
I second Steve on the point below.. I have pulled out many a hair trying to get
complex datatypes to send/parse correctly between different platforms. They work
nicely between CF and CF, but try with CF and .NET and the 'fun' begins.
Regards,
Adam
-Original Message-
From:
@steve + @adam; thanks for that advice. I'm glad I asked before I went
and refactored all the code. Thanks a million. I'll be interested to
see what others have to say.
On Nov 11, 2:32 pm, Adam Chapman [EMAIL PROTECTED] wrote:
Hi Matthew,
I second Steve on the point below.. I have pulled out
Yeah, Dream on! :-)
Well - they are coverted to SOAP equivalents, nothing wrong so far.
As Steve has pointed out - there are various complex issues when it
comes to complex data types cross-platform interoperability - converting
types to .NET is one of the easier tasks. Start about including
Perhaps the answer is to provide 2 web service interfaces - one for
XML consumers and the other for SOAP consumers. If you build the XML
version first it shouldn't be that hard to build a SOAP version as
well... as long as the web service's have absolutely no business logic
in them. The SOAP web
@Steve, true but if you are trying to minimise work for the consumer /
client and they preferred SOAP than all I'm pointing out is that it
shouldn't be too hard to accommodate this. Going for the XML method as
the main web service interface make sense. Thanks everyone for your
help.
Cheers
10 matches
Mail list logo
