Rob Gonda's Blog

help: coldfusion+soap

ColdFusion has a nice integration with web services when a WSDL is present, and it's great with REST web services too. However, it's extremely difficult to integrate with regular soap, why?!

I tried using cfx_soap and it just doesn't work. I also found a way to 'trick' cf by creating a local web services and then add soap headers to it... but it's too complicated, and only works for cfmx6.1. Of course I could manually code all the xml envelop and use regular cfhttp calls, but who wants to do that?

Has anyone successfully implemented any soap integration with CF? If so, could so share it with the community? Just to think that perl can use soap::lite modules and CF can't... how depressing.

Thanks.

ColdFusion Open Source list now using ajaxCFC

The ColdFusion community open source projects list is growing, and there are several individuals helping the cause. Brian Rinaldi put together a very nice list of open source projects. After I changed my license, he chose to incorporate it to the site and use it for category filtering, and as expected, it's much faster than page reloads. Read how difficult was the experience from download to deploy on a very useful beginner's review of ajaxCFC.

Ajax: XMLHttpRequest Vs. iFrames

In my resent presentation in the CFUG someone asked me why should he switch from using iframes to XHR and I stumbled a little. There is not better or worse when comparing these two techniques, but they are certainly different. While both of them allow you to communicate with the server in the background, you should choose the appropriate for your situation depending on a few questions: Do you want the back-forward buttons to work? Do you plan to perform more than one simultaneous request? Do you need cross-site calls? Do you need to monitor the status of your calls?

I'm pretty sure there are more differences, and way around the ones I will mention for either technique, but out of the box, here are the differences:

                            XHR           iFrame
Multithread:       yes             no
Back button      no               yes
Cross-site        no               yes
Statuses           yes             no

Some people use iframes because it's easier to monitor… all you have to do is to show the hidden iframe and voila, you see the responses. On the other hand, I use several http traffic sniffers that give me even more accurate information, and they're extremely easy to use. So that's not a plus for me.

Multithread is huge... you could achieve this with iframes if you create a framework that will create a new iframe using dom, use it for the call and delete it once it's completed. When using XHR, you can easily create a new remote request with simple scripting.

The back button breaks by default when using XHR. Sometimes it is actually good, f.e, if I populate a city and state using a zip code, or check if an email has been taken prior to submitting a form I wouldn't like to add a history step, so I'm glad the back button doesn't recognize that request. There are ways around it too if you do need it to work. I will post some solutions/possibilities soon.

Cross-site scripting ... while you would like this to work to use web services, they do not really work with iframes either. When scripting with iframe you need to explicitly call a function in the parent or top window, so unless you control both sites, this advantage is useless. You can implement a server side web service proxy relatively easy and I would suggest doing that if you need to use WS.

Finally, statuses... with an iframe you do not know in that status your call is. With XHR you have 5 different ones: 0 = uninitialized, 1 = loading, 2 = loaded, 3 = interactive, 4 = complete. They are useful to provide the user with more accurate information.

In conclusion, most of the times XHR is preferable over iframes, but there are cases and cases. Google maps uses iframes, while google suggest uses XHR.

This blog is running version 5.9.003. Contact Blog Owner