While I definitely agree with your first paragraph, an additional layer of server side applications seems a bit much for something that is in fact, natively supported, and well I might add, by the application server itself. XML generation with ColdFusion is trivial.
All that really needs to be done is to define the standard, implement the client consumption and generation libraries (js...) and the server side libraries (in our case, probably some ColdFusion components). It seems like all of this can be accomplished without another server side technology/communication chain. Have you considered just licensing the .js and creating server side solutions per platform (CF, J2EE, .NET) that don't require the additional service/application? I'll be curious to see how Jim's project works out. - Calvin Btw, New Atlanta appears to shy away from using the word ColdFusion in reference to the BD product, so I'm not entirely sure that ColdFusion components is accurate in the context below. -----Original Message----- From: Terry Nisenbaum [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 11:31 PM To: CF-Talk Subject: Re: Ajax and CFCs As various AJAX implementations popup on a weekly basis now, it is going to be quite important for all the vendors to settle on the client/server XML protocol. This reminds me of the early days of SOAP. Different companies initially tried to do it their own way, and if W3C would not step in and standardize the protocol, integration through web services would be a mess now. Something very similar should happen with AJAX. In the ideal world an AJAX client should be able to talk to any kind of implementation regardless whether it is written in ColdFusion of C#. In fact, one should be able to swap the underlying implementation of an AJAX powered webapp and no one should notice the difference. The benefits of that approach are huge - no vendor lockin and simplified (seamless) application integration come to mind. Since there is no standard client/server XML protocol, our product (WebORB)implements something we came up - WOLF (Web Object Literal Format). The protocol is flexible and supports all possible data types: primitives, dates, strings, complex objects, arrays, pointers, etc. The same protocol is used to enable communication between an AJAX client and ColdFusion components, .NET or Java objects and XML Web Services. With regards to CFCs, WebORB can serialize all available data types as method arguments or return values. The client side library (Rich Client System) we provide implements the protocol and can create native JS objects representing the server-side counterparts (primitives, dates, arrays, structs, ResultSets for CFQUERY, etc). The same library also provides a very easy-to-use object binding API, so, for example, to bind to a CFC from JavaScript one would do the following: var cfcProxy = webORB.bind( "mycomponent", "http://weborburl"; ); // now you can invoke any method on the CFC identified as "mycomponent" cfcProxy.helloWorld(); // to invoke the same method asynchronously, do the following var async = new Async( processResult ); cfcProxy.helloWorld( async ); // handle the asynchronous result function processResult( result ) { // result is whatever your CFC returned from the helloWorld() function } You can see a bunch of detailed invocation examples here: http://www.themidnightcoders.com/examples/ajaxdotnetguide.htm Currently the CFC support is available only with BlueDragon. cheers, Terry ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215565 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
