Re: Ajax and CFCs
On Wednesday 14 September 2005 17:50, Matthew Blatchley wrote: Very cool.. I've taken another look. It is, indeed, very very cool. (Briefly, seemless data binding of javascript to remote (java|.net) classes with Ajax). And it's free (apperently) for commercial use. :forwards widely. -- Tom Chiverton Advanced ColdFusion Programmer ~| 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:218383 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
The page I posted seems to have disappeared this one works OK: http://www.themidnightcoders.com/examples/phonebook.htm Very impressive demo, I found it here: http://blog.newatlanta. com /weborb/examples/richclientprimer/javascript-ajax/phonebook-bluedragon. cfm curious as to why it can't be made to work under CFMX? !! :) Andrew ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218230 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
Re: Ajax and CFCs
On Wednesday 14 September 2005 16:29, Andrew Grosset wrote: http://www.themidnightcoders.com/examples/phonebook.htm Doesn't work (Konqueror). -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218239 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
What is the WebORB server? Is this example using CFC's or is the data lookups done from the WebOrb Server? - Original Message - From: Thomas Chiverton [EMAIL PROTECTED] To: CF-Talk cf-talk@houseoffusion.com Sent: Wednesday, September 14, 2005 11:19 AM Subject: Re: Ajax and CFCs On Wednesday 14 September 2005 16:29, Andrew Grosset wrote: http://www.themidnightcoders.com/examples/phonebook.htm Doesn't work (Konqueror). -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218248 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
Ah WebORB Presentation Server is a platform for building, deploying and hosting rich client applications. The product is available for the Microsoft .NET and Java environments. It natively supports AJAX and Flash Remoting clients and provides connectivity to Java and NET objects, XML Web Services, EJBs and ColdFusion Components Very cool.. - Original Message - From: Matthew Blatchley [EMAIL PROTECTED] To: CF-Talk cf-talk@houseoffusion.com Sent: Wednesday, September 14, 2005 11:36 AM Subject: Re: Ajax and CFCs What is the WebORB server? Is this example using CFC's or is the data lookups done from the WebOrb Server? - Original Message - From: Thomas Chiverton [EMAIL PROTECTED] To: CF-Talk cf-talk@houseoffusion.com Sent: Wednesday, September 14, 2005 11:19 AM Subject: Re: Ajax and CFCs On Wednesday 14 September 2005 16:29, Andrew Grosset wrote: http://www.themidnightcoders.com/examples/phonebook.htm Doesn't work (Konqueror). -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218252 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
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:56 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm Here's an odd one. This packet: valuearraydatavaluestructmembernameprop1/namevaluestring val1/string/value/membermembernameprop2/namevaluestringval2 /string/value/member/struct/valuevalueboolean1/boolean/value /data/array/value Through your parser produces two arrays (an outer one with one element and an inner one with the two specified elements). That don't seem right... I'm making the assumption (probably a good one) that the problem is on my end... but I'm stumped as to what it is. Any ideas? What'd I do wrong? Thanks, Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215882 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
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
I'm making the assumption (probably a good one) that the problem is on my end... Jim: It's not a problem... just confusion brought on by a lack of explanation. That outer array is the array of params... you can safely ignore it. To make things clearer, I added a second CFDUMP that displays the deserialized package by itself. -- Roger Benningfield ~| 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:215895 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 10:50 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) I'm making the assumption (probably a good one) that the problem is on my end... Jim: It's not a problem... just confusion brought on by a lack of explanation. That outer array is the array of params... you can safely ignore it. To make things clearer, I added a second CFDUMP that displays the deserialized package by itself. Cool... I like problems that end up not being problems. ;^) I need a lot more testing but so far, so good. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215917 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
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Mostly because I'd never heard of it until you mentioned it. Where have you been for the past two weeks while I've been ranting about not having something like this. ;^) Jim: I only skim the list, in general. I'm surprised I didn't notice the conversation, though... I have watchlists set up for XML and RSS for CFTalk, since those are the two areas where I'm best positioned to be helpful. I have no idea why they failed in this instance. It does look good - it's just odd that in my posting/searching I never came across it. You were probably one search term away... that's how it always works out for me. Although if it helps, I had an article/CFC published in DRK4 that addresses XML-RPC in CF. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215877 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
But although the system does seem to be well supported it also seems to be poorly documented. ;^) Jim: That's a matter of perspective. Some people love Dave Winer's approach to spec-writing, and some people absolutely *loathe* it. I'm gonna guess you're in the latter group. :D - Convert a null into an empty value: value/value. - Convert a null into an empty string: string/string. - Throw an error. I can't say conclusively, but I would opt for the first or third choice. If you can afford the ambiguity, the first is the best... most implementations (including mine) will interpret an empty value / as a zero-length string, but at least it leaves open the possibility for other implementations. Any idea about what's right? Technically, XML-RPC dates have no timezone. Apps are expected to set timezones in another method, or within another param in the current method. In practice, my (de)serializer respects the above... but the instant it returns the value to my main code, I promptly assume that it is UTC and go from there. :-) +) String formatting seems... odd. The spec claims that only ampersands and less-than signs should be escaped - is this right? Not even greater-than signs? Nothing for control characters? Basically, it's saying do what you would normally do to escape any off-limits XML characters. Technically, greater-than signs don't need to be escaped as long as you escape any less-thans, but most of us do it anyway, just to be safe. Probably the easiest thing to do is just wrap strings in ![CDATA[]], although there may be an oddball deserializer out there that will barf. If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm and enter any of your serialized chunks into the form. It will wrap whatever you input in a method/param, deserialize it, and CFDUMP the results. I don't claim that my (de)serializer is any kind of benchmark, but it'll at least let you know if you're heading down the right path. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215879 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
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:56 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) But although the system does seem to be well supported it also seems to be poorly documented. ;^) Jim: That's a matter of perspective. Some people love Dave Winer's approach to spec-writing, and some people absolutely *loathe* it. I'm gonna guess you're in the latter group. :D I don't feel that strongly about it either way. ;^) It just seems like some pretty big things are missing from the documentation which could easily result in incompatible parsers... I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm and enter any of your serialized chunks into the form. It will wrap whatever you input in a method/param, deserialize it, and CFDUMP the results. I don't claim that my (de)serializer is any kind of benchmark, but it'll at least let you know if you're heading down the right path. Very Cool - thanks! With some quick passes the serializer seems to work with it. I've just finished the JS deserializer (well - at least the first draft - it's not tested yet). Feel like throwing me some test packets? ;^) It's not fully tested but I've now got a single JavaScript object that will serialize and deserialize from JSON, WDDX, XMLRPC (data only) and my own YODEL format. I'm sure it's buggy as hell... but everything works with simple stuff so far. I'm too beat right now but I'll post it for download tomorrow. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215881 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
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was one of the big points made when Jeremy Allaire and I were discussing his idea of embedding raw data in RSS feeds a couple years ago... not only is it more lightweight than WDDX or SOAP, there's virtually no language or environment that doesn't already support it. That kind of ubiquity is hard to ignore. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215757 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 10:04 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? Mostly because I'd never heard of it until you mentioned it. Where have you been for the past two weeks while I've been ranting about not having something like this. ;^) XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was It does look good - it's just odd that in my posting/searching I never came across it. While I've a bit too much invested in YODEL right now to stop I think I'll still add XML-RPC support (at least for the data format if not for the method calls) to my serialization libraries. Thanks! (Although I still wish you had spoken up two weeks ago. ;^) ) Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215798 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 10:04 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was one of the big points made when Jeremy Allaire and I were discussing his idea of embedding raw data in RSS feeds a couple years ago... not only is it more lightweight than WDDX or SOAP, there's virtually no language or environment that doesn't already support it. That kind of ubiquity is hard to ignore. Okay - I've added XML-RPC data support to my JS serializer extensions. But although the system does seem to be well supported it also seems to be poorly documented. ;^) Right now I'm only creating object-to-string serializers so my solution doesn't actually implement the full method call - it just creates a single the data tag from any JS object. Some questions, if you have the time: +) The system doesn't support explicit nulls (which is fine) but how should a serializer react to them? I can see at least a few ways for handing this: - Convert a null into an empty value: value/value. - Convert a null into an empty string: string/string. - Throw an error. I've assumed the first solution (which I think should work across implementations) but it seems odd that this is left the impelementation. +) The date format for an implementation is sketchy. I've made the assumption that dates will be serialized into UTC dates (with the specified trailing Z) but I see than other implementations either use local time or don't use the trailing Z to indicate UTC. Any idea about what's right? +) String formatting seems... odd. The spec claims that only ampersands and less-than signs should be escaped - is this right? Not even greater-than signs? Nothing for control characters? That's about it... Anyway I've added the serializer to the JS stuff I've been doing and provided examples and source code here: http://www.depressedpress.com/DepressedPress/Test/ If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215843 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
WDDX Replacement Attempt (was RE: Ajax and CFCs)
[Sorry - I posted this in CFCommunity already but all the action seems to be over here...] I've worked on it some more and have something that, on paper, seems good to me. I've built a JavaScript Serializer (but haven't yet begun to tackle the deserializer). I've created and validated the XSD as well. The basic idea, again, is a solution which can transfer structured data between JavaScript (or, really, any client - but primarily client-side JavaScript) and a server. By structured data I mean things like arrays and objects (structs) nested however deeply you want. My (simplified) goals (and complaints against other solutions) were: +) Something that's easy to parse for JavaScript. SOAP is NOT easy to parse (which is, I think, why there's no generalized SOAP parser for JS). +) Something that maintains general data types. SOAP maintains complex datatypes (based on Java or C+). JSON doesn't offer data typing at all. I thought we needed a middle ground. +) Something in XML. Nearly all modern languages deal with XML natively. The DOM makes dealing with it in JavaScript easy (if tedious). It seemed the way to go. +) Something which could be described using modern XML tools. WDDX, for example, can't be described using an XSD... which may be stupid on the W3C's part but is true nonetheless. But XML/XSD provides a basic level of validation that would have to be built from scratch otherwise. +) Something that's appropriate for both download AND upload traffic. +Often the acts of serializing or deserializing things is left to the server which outputs raw JavaScript code. Or JavaScript is left to receive structured data but is left with only flat form fields to respond. +) Finally, and not the most important, I wanted something that would be relatively small. JSON is VERY small (adding only 5-10% to most data packets) while SOAP or WDDX were VERY big (something quintupling the size of data packets). Again, I thought there should be a middle ground without losing capability. I wanted something to take a complex JavaScript object and pass it, intact, to a server which could take the resulting object, modify it and pass it back, intact. I wanted something JavaScript could both serialize and deserialize relatively quickly and easily. Most importantly I wanted something that _I_ could build and understand in JavaScript and that wouldn't take me a month to do! Lastly I wanted something so simple that it would be easy to recreate in other languages as well. And yet powerful enough not to leave (most) people accepting compromises in their data. So, I've come up with this. I call it dataML (have you got something better?): Three tags only (I decided to minimize them to abbreviations since I'm only using two tags): dataML: This is the wrapper tag for the packet. It can contain, first, any number or zero md tags and one d tag. d: Data. This tag contains the data items. It can contain as many other d tags as you like in an orgasmic orgy of nesting. (By having only one tag we eliminate problems that XSD has with randomly appearing child tags.) It take three attributes: type: The type of the data. I settled on using JavaScript's generalized types (plus the addition of binary). If not provided the data type will default to string. Possible values are: +) object (equivalent to a CF Struct) +) array (single dimensional with sparse arrays supported) +) null +) undefined (I'm not sure if this is actually needed yet) +) string +) number +) boolean (true or false are the only acceptable values.) +) date +) binary (BASE64 Data) +) function (representing a JavaScript function. fields: For objects this is a comma-delimited list of the properties of the object (or, for CF, the keys of a struct). For arrays, if used at all, it would be the indexes filled in a sparse array. It's ignored for all other data types. label: A label which corresponds to a label using in a md (metadata) tag. If used the other attributes will be pulled from the metadata. md: MetaData. This allows us to create a set of attributes to be applied later to multiple data items. While its use may slow down serialization/deserialization using it well can shrink the size of the resulting packet tremendously. We can use md to pre-populate attribute values for d tags. It takes one attribute: label: A label which identifies the metadata. This will be used in the label attribute of d tags. md tags must appear BEFORE d tags. But examples probably say it better. A simple, two property object could be displayed like this: dataML d type=object fields=fname, mname, lname, d type=stringJim/d d type=null / d type=stringDavis/d /d /dataML Where a simple record set could look like this: dataML d type=array d
RE: Ajax and CFCs
-Original Message- From: Terry Nisenbaum [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 11:31 PM To: CF-Talk Subject: Re: Ajax and CFCs 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. Too true... this is what I've been ranting about. ;^) 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 Have you published the dialect or an XSD for it? Are you planning on it? It looks interesting but, to be blunt, it looks a whole heck of a lot like WDDX (although actually much more verbose - even the simple example on the page you reference returns a 12kb packet). It's definitely simpler than SOAP (which can only be good). But if it stays a proprietary solution I'm not sure how it will help the situation overall. Don't get me wrong - it's all very cool stuff and, I'm sure, insanely useful, but it doesn't seem as if you're addressing the problem you starting talking about (lack of a broad standard). Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215550 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
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis ~| 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:215551 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
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Interesting ideas and it seems like a good direction. The use of the word object seems to trip me up (since I always think of objects as having both values ( properties ) and funcionality ( methods )...) Going to be tough on a name, most of the 4/5 letter ...ml options have been used at this point... - Calvin -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 2:09 AM To: CF-Talk Subject: WDDX Replacement Attempt (was RE: Ajax and CFCs) [Sorry - I posted this in CFCommunity already but all the action seems to be over here...] I've worked on it some more and have something that, on paper, seems good to me. I've built a JavaScript Serializer (but haven't yet begun to tackle the deserializer). I've created and validated the XSD as well. The basic idea, again, is a solution which can transfer structured data between JavaScript (or, really, any client - but primarily client-side JavaScript) and a server. By structured data I mean things like arrays and objects (structs) nested however deeply you want. My (simplified) goals (and complaints against other solutions) were: +) Something that's easy to parse for JavaScript. SOAP is NOT easy to parse (which is, I think, why there's no generalized SOAP parser for JS). +) Something that maintains general data types. SOAP maintains complex datatypes (based on Java or C+). JSON doesn't offer data typing at all. I thought we needed a middle ground. +) Something in XML. Nearly all modern languages deal with XML natively. The DOM makes dealing with it in JavaScript easy (if tedious). It seemed the way to go. +) Something which could be described using modern XML tools. WDDX, for example, can't be described using an XSD... which may be stupid on the W3C's part but is true nonetheless. But XML/XSD provides a basic level of validation that would have to be built from scratch otherwise. +) Something that's appropriate for both download AND upload traffic. +Often the acts of serializing or deserializing things is left to the server which outputs raw JavaScript code. Or JavaScript is left to receive structured data but is left with only flat form fields to respond. +) Finally, and not the most important, I wanted something that would be relatively small. JSON is VERY small (adding only 5-10% to most data packets) while SOAP or WDDX were VERY big (something quintupling the size of data packets). Again, I thought there should be a middle ground without losing capability. I wanted something to take a complex JavaScript object and pass it, intact, to a server which could take the resulting object, modify it and pass it back, intact. I wanted something JavaScript could both serialize and deserialize relatively quickly and easily. Most importantly I wanted something that _I_ could build and understand in JavaScript and that wouldn't take me a month to do! Lastly I wanted something so simple that it would be easy to recreate in other languages as well. And yet powerful enough not to leave (most) people accepting compromises in their data. So, I've come up with this. I call it dataML (have you got something better?): Three tags only (I decided to minimize them to abbreviations since I'm only using two tags): dataML: This is the wrapper tag for the packet. It can contain, first, any number or zero md tags and one d tag. d: Data. This tag contains the data items. It can contain as many other d tags as you like in an orgasmic orgy of nesting. (By having only one tag we eliminate problems that XSD has with randomly appearing child tags.) It take three attributes: type: The type of the data. I settled on using JavaScript's generalized types (plus the addition of binary). If not provided the data type will default to string. Possible values are: +) object (equivalent to a CF Struct) +) array (single dimensional with sparse arrays supported) +) null +) undefined (I'm not sure if this is actually needed yet) +) string +) number +) boolean (true or false are the only acceptable values.) +) date +) binary (BASE64 Data) +) function (representing a JavaScript function. fields: For objects this is a comma-delimited list of the properties of the object (or, for CF, the keys of a struct). For arrays, if used at all, it would be the indexes filled in a sparse array. It's ignored for all other data types. label: A label which corresponds to a label using in a md (metadata) tag. If used the other attributes will be pulled from the metadata. md: MetaData. This allows us to create a set of attributes to be applied later to multiple data items. While its use may slow down serialization/deserialization using it well can shrink the size of the resulting packet tremendously. We can use md to pre-populate attribute values
RE: Ajax and CFCs
Microsoft provides a free webservice.htc to accommodate SOAP operations with Javascript. There are several good implementations for SOAP support in Javascript. Bindows for example depends on it. Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Terry Nisenbaum [mailto:[EMAIL PROTECTED] Sent: donderdag 18 augustus 2005 5:09 To: CF-Talk Subject: Re: Ajax and CFCs You mean like web services or WDDX? mike chambers Yes, I mean something like SOAP. SOAP would be a good candidate to implement in JavaScript (Flash already has it), but the protocol has gotten to be too complex and getting it right would be a complicated task - eventually it may not worth the effort. Even in Flash, some things still do not work right (for example when you have to customize target namespace for an operation). I believe there should be a simple platform neutral XML-based protocol that would allow integration of a rich client with any kind of server side component cheers, Terry ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215563 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
RE: Ajax and CFCs
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
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why not dpxl, seeing as it's not a markup language so much as a data
transfer language that happens to an XML application?
Jim Davis wrote:
+) Something that's easy to parse for JavaScript. SOAP is NOT easy to
parse (which is, I think, why there's no generalized SOAP parser for JS).
+) Something that maintains general data types. SOAP maintains complex
datatypes (based on Java or C+). JSON doesn't offer data typing at all. I
thought we needed a middle ground.
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
typing doesn't imply weak typing, nor does a paucity of type annotation
imply dynamic typing. For the former, see Python, which has strong
dynamic typing, and for the latter, see Haskell and ML, which both have
strong static typing through use of type inference[1].
If you're willing to extend things a little bit by including the syntax
new X(comma seperated list of elements), you can represent dates and
binary data too. I don't see any need for undefined, which can be
denoted by simple absence of data, or function, which ties things to
JavaScript even more tightly, in which case you'd might as will go the
JSON route anyway.
That said, I'm not arguing in favour of JSON so much as pointing out
that by perceived typelessness on its part is not quite the case.
I'd include some kind of explicit recordset type too.
Three tags only (I decided to minimize them to abbreviations since I'm only
using two tags):
dataML: This is the wrapper tag for the packet. It can contain, first,
any number or zero md tags and one d tag.
d: Data. This tag contains the data items. It can contain as many
other d tags as you like in an orgasmic orgy of nesting. (By having only
one tag we eliminate problems that XSD has with randomly appearing child
tags.)
It take three attributes:
type: The type of the data. I settled on using JavaScript's
generalized types (plus the addition of binary). If not provided the data
type will default to string. Possible values are:
+) object (equivalent to a CF Struct)
+) array (single dimensional with sparse arrays supported)
+) null
+) undefined (I'm not sure if this is actually needed yet)
+) string
+) number
+) boolean (true or false are the only acceptable
values.)
+) date
+) binary (BASE64 Data)
+) function (representing a JavaScript function.
I'd say it would actually be less bulky if you changed the names of the
types into tags.
d type=null/
null/
d type=booleantrue/d
booleantrue/boolean
dataML
d type=object fields=fname, mname, lname,
d type=stringJim/d
d type=null /
d type=stringDavis/d
/d
/dataML
dpxl
object fields=fname,mname,lname
stringJim/string
null/
stringDavis/string
/object
/dpxl
{fname: Jim, mname: null, lname: Davis}
Where a simple record set could look like this:
dataML
d type=array
d type=object fields=text, value,
d type=stringFund One/d
d type=stringFund01/d
/d
d type=object fields=text, value,
d type=stringFund Two/d
d type=stringFund02/d
/d
d type=object fields=text, value,
d type=stringFund Three/d
d type=stringFund03/d
/d
/d
/dataML
dpxl
array
object fields=text,value
stringFund One/string
stringFund01/string
/object
object fields=text,value
stringFund Two/string
stringFund02/string
/object
object fields=text,value
stringFund Three/string
stringFund03/string
/object
/array
/dpxl
[
{text: Fund One, value: Fund01},
{text: Fund Two, value: Fund02},
{text: Fund Three, value: Fund03}
]
But over large numbers of records the repetition of the metadata would
inflate the packet terribly. So we use the md tag like so:
dataML
md label=option
d type=object fields=text, value,
d type=string /
d type=string /
/d
/md
d type=array
d label=option
dFund One/d
dFund01/d
/d
d label=option
dFund Two/d
dFund02/d
/d
d label=option
dFund Three/d
dFund03/d
/d
/d
/dataML
This shrinks the serialized version of the data tremendously when you want
to return large numbers of similar objects (as with a record set).
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
dataML
type name=option
d type=object fields=text,value
d type=string /
d type=string /
/d
/type
d
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
At 02:33 AM 8/18/2005, you wrote: Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) How about DEML [dimmel] for data expression or exchange ML? -- Phillip Beazley Onvix -- Website Hosting, Development E-commerce Visit http://www.onvix.com/ or call 727-578-9600. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215569 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On Thursday 18 August 2005 10:04, Micha Schopman wrote: Microsoft provides a free webservice.htc to accommodate SOAP operations with Javascript. ..htc aren't real web pages. -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215597 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis XML Data Language (XDL) XML Data Format (XDF) XML Information Language (XIL) XML Information Format (XIF) s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215614 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
RE: Ajax and CFCs
-Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 5:04 AM To: CF-Talk Subject: RE: Ajax and CFCs Microsoft provides a free webservice.htc to accommodate SOAP operations with Javascript. This component doesn't actually work with CF Services (or, really, any non-.NET services). Although a guy named Bill Hepola addressed some of the more basic problems so that it would, at least, accept simple values from CF it still can't be used with any complex objects. There are several good implementations for SOAP support in Javascript. Bindows for example depends on it. Not exactly portable to other apps, is it. ;^) Bindows is a commercial application framework... there may be a good JS implementation of SOAP someplace in there, but it's not really useful to the average developer. I suppose I should have been explicit that there are no good JavaScript SOAP implementations that have been made available to the broader AJAX community. All of the ones that I find are embedded into expensive commercial apps or large interface abstraction layers. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215623 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
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
XIEF (XML Information Exchange Format) -Original Message- From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:33 AM To: CF-Talk Subject: RE: WDDX Replacement Attempt (was RE: Ajax and CFCs) Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis XML Data Language (XDL) XML Data Format (XDF) XML Information Language (XIL) XML Information Format (XIF) s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215628 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
RE: Ajax and CFCs
-Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:08 AM To: CF-Talk Subject: Re: Ajax and CFCs On Thursday 18 August 2005 10:04, Micha Schopman wrote: Microsoft provides a free webservice.htc to accommodate SOAP operations with Javascript. ..htc aren't real web pages. Well - they're not web pages at all. ;^) HTC is a Hyper Text Component - basically an encapsulated behavior. It can't be used on it's own at all. HTCs are used to extend HTML pages and HTA applications. There are still several problems with the HTC however (I evaluated it extensively): +) It doesn't work with CF web services. It just doesn't. There's a hacked version floating around from Bill Hepola that fixes some of the problems... but even then you can only pass simple data (the complex data structures in SOAP differ between CF and .NET and only the .NET ones are supported). +) It only works on IE 5 or above. Nothing else. (This actually would have been fine for me since I'm actually building an HTA... but the other problems scuttled it.) +) MS no longer supports this component. They also no longer support the replacement for this component (the SOAP com library). As of now they SOAP natively in .NET and that's it - no more extensions/libraries. +) Using this extension is tedious. HTC's are DHTML behaviors (actually a great concept unique to IE 5+) so you must link the behavior to the style of an element. This works and all but the forced coupling of what should be a low-level transfer library to the interface seems very odd. There really nothing in the code that couldn't have been done in regular JavaScript... unless they just used an HTC to explicitly force the idea of IE 5+. All told I worked for several days trying to get this HTC to work with even simple CF or Java services and got no joy. But if you're doing IE 5+ development against a .NET server it should actually be quite nice to work with. ;^) Jim Davis ~| 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:215630 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
Re: Ajax and CFCs
Jim, we plan to publish a schema for the protocol. It hasn't been done yet since the product is in Beta and want to make sure everything is done right and works as intended. When the schema is published it will be contributed to the public domain, so other can contribute and use it in their own projects. -Original Message- Too true... this is what I've been ranting about. ;^) 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 Have you published the dialect or an XSD for it? Are you planning on it? It looks interesting but, to be blunt, it looks a whole heck of a lot like WDDX (although actually much more verbose - even the simple example on the page you reference returns a 12kb packet). It's definitely simpler than SOAP (which can only be good). But if it stays a proprietary solution I'm not sure how it will help the situation overall. Don't get me wrong - it's all very cool stuff and, I'm sure, insanely useful, but it doesn't seem as if you're addressing the problem you starting talking about (lack of a broad standard). Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215631 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
Jim, Contact me off list about WDDX. Rey... Jim Davis wrote: -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:08 AM To: CF-Talk Subject: Re: Ajax and CFCs On Thursday 18 August 2005 10:04, Micha Schopman wrote: Microsoft provides a free webservice.htc to accommodate SOAP operations with Javascript. ..htc aren't real web pages. Well - they're not web pages at all. ;^) HTC is a Hyper Text Component - basically an encapsulated behavior. It can't be used on it's own at all. HTCs are used to extend HTML pages and HTA applications. There are still several problems with the HTC however (I evaluated it extensively): +) It doesn't work with CF web services. It just doesn't. There's a hacked version floating around from Bill Hepola that fixes some of the problems... but even then you can only pass simple data (the complex data structures in SOAP differ between CF and .NET and only the .NET ones are supported). +) It only works on IE 5 or above. Nothing else. (This actually would have been fine for me since I'm actually building an HTA... but the other problems scuttled it.) +) MS no longer supports this component. They also no longer support the replacement for this component (the SOAP com library). As of now they SOAP natively in .NET and that's it - no more extensions/libraries. +) Using this extension is tedious. HTC's are DHTML behaviors (actually a great concept unique to IE 5+) so you must link the behavior to the style of an element. This works and all but the forced coupling of what should be a low-level transfer library to the interface seems very odd. There really nothing in the code that couldn't have been done in regular JavaScript... unless they just used an HTC to explicitly force the idea of IE 5+. All told I worked for several days trying to get this HTC to work with even simple CF or Java services and got no joy. But if you're doing IE 5+ development against a .NET server it should actually be quite nice to work with. ;^) Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215632 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Keith Gaughan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 7:57 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why not dpxl, seeing as it's not a markup language so much as a data transfer language that happens to an XML application? Perhaps... I do like to add dp to things. ;^) Not quite true. The data typing in JSON is implicit. Of the types listed below it can unambiguously represent object, array, null, string, string, boolean, and number. It's all implicit in the syntax. Dynamic That's true I guess. But there IS more: JSON also can't represent non-numeric keyed arrays (something called JavaScript Hashtables) for example. I had considered extending the JSON syntax but decided against it on principle: the beauty and simplicity of any JSON packet is that it IS JavaScript code. Any extensions would break that elegance... so I didn't want to touch it. (As an aside - I really like JSON a lot... the JS library I'm bulding for this stuff will also do JSON... I actually envision an application that's smart enough to know which transport mechanism is required based on the complexity being transferred...) I'd include some kind of explicit recordset type too. I consider that for a long... long time... but decided against it. Any representation of a recordset I've ever seen is either column-based (which is an object whose properties are arrays) or record-based (which is an array of objects). Both of these representations can be done using Arrays and Objects so why is it really needed? Either we create a custom RecordSet object in JS or we convert it to the native data types... but since the latter is just as easy as the first for JS why bother? I'd say it would actually be less bulky if you changed the names of the types into tags. d type=null/ null/ d type=booleantrue/d booleantrue/boolean The main problem here is that it's impossible to describe such a language an XSD (unless you allow any tag - which includes xHTML, made up tags, etc - in any place). XSD only allows a tag to contain ordered tags or any tags (so the former would force us to say that object must appear before array which must appear before string and so forth - which makes the serialization an order of magnitude more complex). This shrinks the serialized version of the data tremendously when you want to return large numbers of similar objects (as with a record set). I'd like to point out that here the md tag is essentially defining a new type, so you could change this to: I could... but in keeping with the theme, if I did do it would probably be a dt (data type) tag. ;^) But I may do this... although I'm comfortable with both concepts if one makes easier for others then, great. dataML type name=option d type=object fields=text,value d type=string / d type=string / /d /type d type=array d type=option dFund One/d dFund01/d /d d type=option dFund Two/d dFund02/d /d d type=option dFund Three/d dFund02/d /d /d /dataML But there are questions. Should default data be allowed in meta data (if you fill in the content of the tags should that content be used if no content is provided in the d tags)? I'd say so, yes. Yeah... I'm leaning that way as well... but I'm also fearing building the deserializer. ;^) Should metadata for the contents of an array automatically apply to ALL children of that array? In other words should this be legal: Definitely. As I said, md is essentially a type declaration, so yes. Mind you, such a generalisation would complicate the serialisers and deserialisers a bit. Yeah... that's a fear. Mostly the Deserializers I think: I still think that, in practice, the whole idea of metadata/custom types will be used only in certain situations an problems require custom code anyway. Since all they do is cut down on verbosity I'm debating on even keeping them... but I do really like the concept. Should such a thing force all children of the array to be the same? Yes, unless you want to reserve the undefined type for use in md to represent somewhere where the types are specified in the body. I was thinking more organically on this one. My thinking would be that the type would only apply as a mask to the linked elements. So, if a child tags type was defined it would apply it, if not it wouldn't. If it defined an object but no properties then that object could have any properties. This is one reason that I'm NOT super comfortable with the type concept... it seems to imply a full definition when it could only part of one. In most cases you won't need the md at all. It's ONLY needed to save space. All deserializers should
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 7:32 AM To: CF-Talk Subject: RE: WDDX Replacement Attempt (was RE: Ajax and CFCs) Interesting ideas and it seems like a good direction. The use of the word object seems to trip me up (since I always think of objects as having both values ( properties ) and funcionality ( methods )...) The basis for (almost all of this) is JavaSript - that's where object comes from. Although note that there is a function type - so, in theory, you can pass objects (at least JavaScript objects) with methods and properties via the dialect. I say in theory because I've no idea about in practice this would work however... ;^) Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215647 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
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Davis wrote:
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
That's true I guess. But there IS more: JSON also can't represent
non-numeric keyed arrays (something called JavaScript Hashtables) for
example.
Ah, but isn't that what an object in JS(ON) essentially is?
{
I am: a string-keyed,
array or: a hashtable,
if: you will.
}
I'd include some kind of explicit recordset type too.
I consider that for a long... long time... but decided against it. Any
representation of a recordset I've ever seen is either column-based (which
is an object whose properties are arrays) or record-based (which is an array
of objects).
Both of these representations can be done using Arrays and Objects so why is
it really needed? Either we create a custom RecordSet object in JS or we
convert it to the native data types... but since the latter is just as easy
as the first for JS why bother?
True, but I was thinking that it might be nice to annote it as such.
The main problem here is that it's impossible to describe such a language an
XSD (unless you allow any tag - which includes xHTML, made up tags, etc -
in any place). XSD only allows a tag to contain ordered tags or any tags
(so the former would force us to say that object must appear before
array which must appear before string and so forth - which makes the
serialization an order of magnitude more complex).
Hmmm... I heard XSD was a bit odd, but I didn't think it was *that* bad.
Holy crap! I think I'll stick with DTDs then.
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
I could... but in keeping with the theme, if I did do it would probably be a
dt (data type) tag. ;^)
Fairy nuff. :-)
Should such a thing force all children of the array to be the same?
Yes, unless you want to reserve the undefined type for use in md to
represent somewhere where the types are specified in the body.
I was thinking more organically on this one.
My thinking would be that the type would only apply as a mask to the
linked elements. So, if a child tags type was defined it would apply it, if
not it wouldn't. If it defined an object but no properties then that
object could have any properties.
You could do that alright. I was just thinking of a situation where you
might have something like this:
dt name=wotsit
d type=array
d type=object fields=id,name,value
d type=number/
d type=string/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
/d
/dt
/dt
Where the value might be an object or an array of objects.
This is one reason that I'm NOT super comfortable with the type concept...
it seems to imply a full definition when it could only part of one.
Nah, types can be just partial definitions of what's going on too.
K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBLk0mSWF0pzlQ04RArLqAKDAsLs7RDuzsykZFgVRVoQ+5rjzegCfTESs
dHAnWesEpA5/BmCam4IiXKI=
=rFSC
-END PGP SIGNATURE-
~|
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:215650
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=89.70.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 18, 2005 12:37 PM
To: CF-Talk
Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Davis wrote:
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
That's true I guess. But there IS more: JSON also can't represent
non-numeric keyed arrays (something called JavaScript Hashtables) for
example.
Ah, but isn't that what an object in JS(ON) essentially is?
{
I am: a string-keyed,
array or: a hashtable,
if: you will.
}
Not really. Sorta/kinda.
JavaScript IS WEIRD - just so we have that straight before we start.
There's definitely a method to its madness, but it IS weird. ;^)
You can do this:
myOb = new Object();
myOb.myProp = value;
AND
myAr = new Array();
myAr[myProp] = value;
However, as alike as they look, doing a typeof for both will still return
object and array.
This is a subtlety to be sure - but one which JSON can't distinguish
between. That last array can't really be done as an array in JSON (the
commonly available JSON parser actually just ignores the values completely).
This is strange, but understandable. In the second case you're adding
properties to an (array) object - perfectly legal. But it is strange (it's
also pretty common in use).
The main problem here is that it's impossible to describe such a
language an
XSD (unless you allow any tag - which includes xHTML, made up tags,
etc -
in any place). XSD only allows a tag to contain ordered tags or any
tags
(so the former would force us to say that object must appear before
array which must appear before string and so forth - which makes the
serialization an order of magnitude more complex).
Hmmm... I heard XSD was a bit odd, but I didn't think it was *that* bad.
Holy crap! I think I'll stick with DTDs then.
Yeah... I probably should have. For me I'm damned if I do, damned if I
don't with XD.
XSD also can't validate based on attribute values - which means it can't
validate much of this at all.
But still... it does work.
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
I could... but in keeping with the theme, if I did do it would probably
be a
dt (data type) tag. ;^)
Fairy nuff. :-)
I was thinking about this more...
The only real problem I see is that I would have to make the type
attribute accept any value (in the XSD at least) - there could be no
validation on type.
I'm not sure how I feel about that... I guess needing to make it optional to
support the md as it was is just as bad, uh?
I'm (like in so many things) back and forth on it.
My thinking would be that the type would only apply as a mask to the
linked elements. So, if a child tags type was defined it would apply
it, if
not it wouldn't. If it defined an object but no properties then that
object could have any properties.
You could do that alright. I was just thinking of a situation where you
might have something like this:
dt name=wotsit
d type=array
d type=object fields=id,name,value
d type=number/
d type=string/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
/d
/dt
/dt
Where the value might be an object or an array of objects.
I would think either we use just plain d / or put nothing at all.
The latter would indicate that although a value could be there - we've got
no attributes to apply to it. User's choice.
A clearer example might do this:
dt name=wotsit
d type=array
d type=object fields=id,value,name
d type=number/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
d type=string/
/d
/dt
/dt
In this case we really need a place holder of some kind to ensure that the
string type will be applied to correct field.
But I still thing an empty d / is best here - since the underlying idea of
this is that attributes of the new type will replace the corresponding
attributes of the linked thing showing this with no attributes will cause no
substitutions.
A key of this is that the custom types aren't enforcing strict adherence (or
at least I don't think they should). Any attributes not defined are left to
the user to fill in as they like.
Sound good?
This is one reason that I'm NOT super comfortable with the type
concept...
it seems to imply a full definition when it could only part of one.
Nah, types can be just
RE: Ajax and CFCs
I agree with you totally on the format. There are several ideas within the W3 for a new format, and they are more or less the direct result of RSS being to leverage complex data. However, I do think this is not an issue with missing a standard. It is the issue of a SOAP standard not being supported0. We can introduce numerous of new standards, but it in the end it all comes down to the vendors supporting it. Even then, I don't think you need standards for everything. There are numerous options in providing your applications with non standardized data but that involves manual work just like the good old days. Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 16:29 To: CF-Talk Subject: RE: Ajax and CFCs \ -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:12 AM To: CF-Talk Subject: RE: Ajax and CFCs The amount of consistency is in the hands of the developer. It just is about documenting the format. You're thinking too small here, Micha. We're not saying we can't get the job done - this isn't a help me get this out the door issue. It's a broader question. Why should such a fundamental thing as passing structured data be left completely to individual implementation? Why should that implementation be tightly coupled to the solution built? Why shouldn't my interface be able to switch from obtaining data from CF to obtaining data from WebSphere without having to rebuild the transport mechanism on WebSphere? The complaint (well... my complaint) is that this is such a low level issue. Passing structured data from a server to a client needs to be solved by EVERY SINGLE person doing AJAX style applications. Yet we have hundreds if not thousands of incompatible solutions. When you see that doesn't it at least indicate to you that a useful umbrella standard would be a useful thing? Again, it's not that it can't be done or that doing a one-off or a personal standard is difficult. It's that the situation is screaming for a clear, widely-adoptable standard. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215389 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
Do you know any AJAX library or code sample that consumes CF web services (SOAP) natively? Neuromancer (http://www.robrohan.com/projects/neuromancer/ ) does. It's quite a bit more complex (as a library) that I would generally like to see and focuses a lot on interface functionality that (I think) from core issues. Unless I'm missing something big (which is very possible) I don't see anything in it that actually converts data from XML to native JS or back (it'll fetch the XML from the service... but it looks like it's up to you to parse it). Yeah it parses it for you. It unmarshals cfc's into native javascript objects and vise versa. -- ~Blog~ http://www.robrohan.com ~The cfml plug-in for eclipse~ http://cfeclipse.tigris.org ~open source xslt IDE~ http://treebeard.sourceforge.net ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215391 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
Re: Ajax and CFCs
Hi, I found another option for creating an AJAX interface to a CF application: calling a CFC's method with the URL parameters, it will return the result in WDDX format. Do you think it is a good solution? Someone mentioned that the WDDX format is pretty old and that the JS code is not updated since a few years, but I don't see a problem with that, unless there are bugs with it. Anyone? Thanks. ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215392 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
Re: Ajax and CFCs
On Tuesday 16 August 2005 17:27, Jim Davis wrote: It's no slower than any other XML standard. It's slower than MM's query2xml, which produces more compact XML. The XMl size is important if are are shifting more than a few dozen records back and forth, and expect enough performance to use it in a key event handler. Maybe that's just my requirements :-) -- Tom Chiverton Advanced ColdFusion Programmer ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215393 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
Re: Ajax and CFCs
On Tuesday 16 August 2005 17:21, Jim Davis wrote: And once that's done you're dealing with native objects which are quick-as-you-please. There is that. And if you go the whole hog and do client-side XSLT to display the content too, that'll be the slowest bit anyway, apart from the actual transfer. I would imagine :-) -- Tom Chiverton Advanced ColdFusion Programmer ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215403 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 4:35 AM To: CF-Talk Subject: Re: Ajax and CFCs Hi, I found another option for creating an AJAX interface to a CF application: calling a CFC's method with the URL parameters, it will return the result in WDDX format. Do you think it is a good solution? Someone mentioned that the WDDX format is pretty old and that the JS code is not updated since a few years, but I don't see a problem with that, unless there are bugs with it. Anyone? All of the implementations are just old (and, because they don't take advantage of any of the modern capabilities, slower than you'd expect) - but most still work fine. There's also a minor issue (depending on how you feel about standards) that the WDDX standard is incompatible with XSD (you can't generate an XSD to describe WDDX). But the long and short of it is: it still works. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215445 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
RE: Ajax and CFCs
-Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 5:07 AM To: CF-Talk Subject: Re: Ajax and CFCs On Tuesday 16 August 2005 17:27, Jim Davis wrote: It's no slower than any other XML standard. It's slower than MM's query2xml, which produces more compact XML. I was actually talking about the parsing time... I doubt that parsing time between the two is dramatically difference even tho' WDDX is more verbose. The XMl size is important if are are shifting more than a few dozen records back and forth, and expect enough performance to use it in a key event handler. Maybe that's just my requirements :-) If you're shifting simple data and don't care about the data type there's really nothing more compact that JSON. It really is an elegant solution to many problems. Jim Davis ~| 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:215446 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On 8/17/05, Jim Davis [EMAIL PROTECTED] wrote: All of the implementations are just old (and, because they don't take advantage of any of the modern capabilities, slower than you'd expect) - but most still work fine. There's also a minor issue (depending on how you feel about standards) that the WDDX standard is incompatible with XSD (you can't generate an XSD to describe WDDX). But the long and short of it is: it still works. I did some tests with a web service (CFC with some methods with remote access) and an AJAX interface, it works great. I can invoke the CFC remotely in two ways: - Regular POST/GET request, the method will return the result in WDDX format. (less data, should be faster) - SOAP request, the moth will return the result in SOAP format. (more data, should be slower) Also, I can invoke the same CFC locally from CFML code (cfinvoke), it works fine too. So far I didn't hit any issue with the WDDX format and the AJAX interface: the JS library works just fine in Firefox, Internet Explorer and Safari. This way I still have a SOAP interface (I could use a Flash client to connect to it in the future, or even Lazlo) and a local interface (I will use CFML code for regular forms, for browser with JS disabled or that don't support the AJAX interface) without duplication of code! That looks great to me, am I missing something? :-) I need to add some security, especially when the CFC methods are called remotely. BTW, I didn't find a good way to tell if a CFC method is invoked locally or remotely, any idea? Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215448 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
RE: Ajax and CFCs
-Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 1:39 PM To: CF-Talk Subject: Re: Ajax and CFCs On 8/17/05, Jim Davis [EMAIL PROTECTED] wrote: All of the implementations are just old (and, because they don't take advantage of any of the modern capabilities, slower than you'd expect) - but most still work fine. There's also a minor issue (depending on how you feel about standards) that the WDDX standard is incompatible with XSD (you can't generate an XSD to describe WDDX). But the long and short of it is: it still works. This way I still have a SOAP interface (I could use a Flash client to connect to it in the future, or even Lazlo) and a local interface (I will use CFML code for regular forms, for browser with JS disabled or that don't support the AJAX interface) without duplication of code! That looks great to me, am I missing something? :-) Not really. I can see a few things worth remembering, but in general - if it works for you, do it. +) Of course it goes without saying that this kind of flexibility is pretty much unique to CF. You can't (and I know you know this) expect to consume none-CF web services in the same way. +) It doesn't really address the issue of passing structured data BACK to the server from the client. Of course you may not need to do this, but being able to would be nice. For example if you wanted to pass a JavaScript array up to the server you'd still have to come up with some sort of translation method. This could be as simple as creating a WDDX packet and putting it in a specifically named field... but it still has to be considered and documented. But it is a nice capability... Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215453 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
I think this was mentioned before, but check out JSON http://www.crockford.com/JSON/index.html It is an very compact format that has libraries for ColdFusion, Flash and JavaScript (among others). mike chambers [EMAIL PROTECTED] Micha Schopman wrote: I agree with you totally on the format. There are several ideas within the W3 for a new format, and they are more or less the direct result of RSS being to leverage complex data. However, I do think this is not an issue with missing a standard. It is the issue of a SOAP standard not being supported0. We can introduce numerous of new standards, but it in the end it all comes down to the vendors supporting it. Even then, I don't think you need standards for everything. There are numerous options in providing your applications with non standardized data but that involves manual work just like the good old days. Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 16:29 To: CF-Talk Subject: RE: Ajax and CFCs \ -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:12 AM To: CF-Talk Subject: RE: Ajax and CFCs The amount of consistency is in the hands of the developer. It just is about documenting the format. You're thinking too small here, Micha. We're not saying we can't get the job done - this isn't a help me get this out the door issue. It's a broader question. Why should such a fundamental thing as passing structured data be left completely to individual implementation? Why should that implementation be tightly coupled to the solution built? Why shouldn't my interface be able to switch from obtaining data from CF to obtaining data from WebSphere without having to rebuild the transport mechanism on WebSphere? The complaint (well... my complaint) is that this is such a low level issue. Passing structured data from a server to a client needs to be solved by EVERY SINGLE person doing AJAX style applications. Yet we have hundreds if not thousands of incompatible solutions. When you see that doesn't it at least indicate to you that a useful umbrella standard would be a useful thing? Again, it's not that it can't be done or that doing a one-off or a personal standard is difficult. It's that the situation is screaming for a clear, widely-adoptable standard. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215514 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 6:47 PM To: CF-Talk Subject: Re: Ajax and CFCs I think this was mentioned before, but check out JSON http://www.crockford.com/JSON/index.html It is an very compact format that has libraries for ColdFusion, Flash and JavaScript (among others). Yes - I really like JSON as well. It's much more compact than XML and lightning fast. It's only real problem (which is kind of a big one) is that it's limited to string literals. There's no data typing at all. Some people find it's lack of extensibility a burden (I don't). It only supports JavaScript style objects (structs) and arrays (but not sparse arrays). There's no specific recordset style and you can't really add one (although you can assume a convention of either an object of arrays or an array of objects). Still - it's a VERY clever idea that leverages a pre-existing nomenclature and should work for a huge number of applications. Jim Davis ~| 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:215518 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
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
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215540
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
Re: Ajax and CFCs
You mean like web services or WDDX? mike chambers [EMAIL PROTECTED] Terry Nisenbaum wrote: Since there is no standard client/server XML protocol, ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215542 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
Re: Ajax and CFCs
You mean like web services or WDDX? mike chambers Yes, I mean something like SOAP. SOAP would be a good candidate to implement in JavaScript (Flash already has it), but the protocol has gotten to be too complex and getting it right would be a complicated task - eventually it may not worth the effort. Even in Flash, some things still do not work right (for example when you have to customize target namespace for an operation). I believe there should be a simple platform neutral XML-based protocol that would allow integration of a rich client with any kind of server side component cheers, Terry ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215543 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
Re: Ajax and CFCs
On 8/15/05, Jim Davis [EMAIL PROTECTED] wrote: Although I'm sure it's incredibly useful to many for current purposes there should be no server-side footprint. CF and BD already do SOAP-based services via CFC, .NET does them automatically as well. WebSphere has built-in thingies. The best solution would be to consume these native services with client-side code. Do you know any AJAX library or code sample that consumes CF web services (SOAP) natively? Thanks. ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215132 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Does that mean that WebORB only supports calls to CFCs on the same server? If so, that looks a big limitation IMHO. Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215133 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
Just wondering, why would you want to communicate with SOAP envelopes in the first place? If you are exchanging data with such complex structures it is clearly a case of the wrong approach towards the Ajax pattern. Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 10:35 To: CF-Talk Subject: Re: Ajax and CFCs On 8/15/05, Jim Davis [EMAIL PROTECTED] wrote: Although I'm sure it's incredibly useful to many for current purposes there should be no server-side footprint. CF and BD already do SOAP-based services via CFC, .NET does them automatically as well. WebSphere has built-in thingies. The best solution would be to consume these native services with client-side code. Do you know any AJAX library or code sample that consumes CF web services (SOAP) natively? Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215134 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On 8/15/05, Christian Cantrell [EMAIL PROTECTED] wrote: CFCs can be invoked directly through the XMLHttpRequest object as long as the CFC support remote access. I tend to cache my components and access them through a controller/proxy which can also be easily done via Ajax. And finally, you can easily call CFM pages directly which return either HTML or XML (the XMLHttpRequest object supports both). You don't need any third-party products. Ajax and ColdFusion go very well together as-is. You can see an example of integration here: http://weblogs.macromedia.com/mxna/reports/categoryFeedReport/index.cfm It looks great! Is the source code available for download? Thanks. ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215138 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
I think so, and in addition it only supports BlueDragon, not ColdFusion. What I think we really need is a solid js library that can convert from common server data types to common js data types so that we aren't locked into another vendor (and in this case a vendor tied to another vendor). Of course as ColdFusion developers, we can create a server side solution that doesn't involve sending the data to an additional layer but at the same time accomplishes the simplification of the data transformation. In fact, doesn't cfajax do something like this, in conjunction with a client side component and is free and available for ColdFusion? I believe someone else was alluding to such a solution earlier as well. - Calvin -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 5:37 AM To: CF-Talk Subject: Re: Ajax and CFCs On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Does that mean that WebORB only supports calls to CFCs on the same server? If so, that looks a big limitation IMHO. Thanks. ~| 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:215141 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
Re: Ajax and CFCs
On 8/16/05, Micha Schopman [EMAIL PROTECTED] wrote: Just wondering, why would you want to communicate with SOAP envelopes in the first place? If you are exchanging data with such complex structures it is clearly a case of the wrong approach towards the Ajax pattern. My plan it to do as little as possible server-side code changes for the AJAX interface. Since my application already uses CFCs, it would be great to re-use the same methods for the AJAX interface. Do you mean that I should avoid complex structures in my AJAX interface? I know that SOAP has some overhead over plain XML data, but I think that the advantage of reusing the same code is a winner here. Please let me know if I am missing something that will prevent me from doing that. Thanks. ~| 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:215142 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
RE: Ajax and CFCs
If you refer back to the WebORB architecture diagram, it supports XML Web Services: http://www.themidnightcoders.com/weborb/aboutWeborb.htm So to the extent that your CFCs are exposed as web services, it appears you could invoke CFCs on another server via web services (and probably even invoke CFCs running on CFMX locally this way). I've never tried this, though, so you'd need to ask the WebORB developers to be sure. Vince -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 5:37 AM To: CF-Talk Subject: Re: Ajax and CFCs On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Does that mean that WebORB only supports calls to CFCs on the same server? If so, that looks a big limitation IMHO. Thanks. ~| 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:215143 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
Re: Ajax and CFCs
On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. -- Tom Chiverton Advanced ColdFusion Programmer ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215144 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
Are there requirements for such changes (AjaxFlash), if not, is this not a clear example of phantom requirements? I personally would not use a CFC in a web service model for supplying the interface with data. I'd rather use a specialized presentation layer providing formatted datasets in a XML stream. This is a far more lightweight solution than SOAP envelopes, and allows future use of a different specialized presentation layer to accommodate different platforms. This specialized layer is also responsible for initially handling post requests. But as I always say, do you want to create widgets following the Ajax design pattern, or do you want to deliver fully blown dynamic interfaces where you limit the chances of hitting a postback event. If it is the latter, expect some heavy studying in all sorts of web technologies and a lot of practice. Many people like to talk about it but those who actually do can be counted on one hand. At least, try to avoid injecting complete code. Try setting up a framework around DOM methods. :) Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 11:48 To: CF-Talk Subject: Re: Ajax and CFCs On 8/16/05, Micha Schopman [EMAIL PROTECTED] wrote: Just wondering, why would you want to communicate with SOAP envelopes in the first place? If you are exchanging data with such complex structures it is clearly a case of the wrong approach towards the Ajax pattern. My plan it to do as little as possible server-side code changes for the AJAX interface. Since my application already uses CFCs, it would be great to re-use the same methods for the AJAX interface. Do you mean that I should avoid complex structures in my AJAX interface? I know that SOAP has some overhead over plain XML data, but I think that the advantage of reusing the same code is a winner here. Please let me know if I am missing something that will prevent me from doing that. Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215148 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
RE: Ajax and CFCs
-Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215203 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
RE: Ajax and CFCs
-Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 5:35 AM To: CF-Talk Subject: Re: Ajax and CFCs On 8/15/05, Jim Davis [EMAIL PROTECTED] wrote: Although I'm sure it's incredibly useful to many for current purposes there should be no server-side footprint. CF and BD already do SOAP-based services via CFC, .NET does them automatically as well. WebSphere has built-in thingies. The best solution would be to consume these native services with client- side code. Do you know any AJAX library or code sample that consumes CF web services (SOAP) natively? Neuromancer (http://www.robrohan.com/projects/neuromancer/ ) does. It's quite a bit more complex (as a library) that I would generally like to see and focuses a lot on interface functionality that (I think) from core issues. Unless I'm missing something big (which is very possible) I don't see anything in it that actually converts data from XML to native JS or back (it'll fetch the XML from the service... but it looks like it's up to you to parse it). But if you can dig in enough it might be exactly you need. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215214 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
RE: Ajax and CFCs
What type of structured data? The only thing you need to pass is XML. A CFML Struct can be serialized into a XMLDocument, and the same counts for Arrays, Lists, Queries, etc. you name it. Maybe I am missing the entire idea behind your goals :) Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 15:22 To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215216 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
Jim - Have you looked at Google's Javascript XSLT parser? It works fairly well - I'm rolling it into some projects right now. It's not a pre-built SOAP parser, but the tools are all there for client-side use. http://goog-ajaxslt.sourceforge.net/ - Other Jim Jim Davis wrote: -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| 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:215217 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
RE: Ajax and CFCs
Yes, but a query will have a consistent xml structure that can then be consistently accessed by JS (think WDDX). I think that's what folks are after. I'm not entirely sure why WDDX isn't being talked about more in regards to AJAX... -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 10:50 AM To: CF-Talk Subject: RE: Ajax and CFCs What type of structured data? The only thing you need to pass is XML. A CFML Struct can be serialized into a XMLDocument, and the same counts for Arrays, Lists, Queries, etc. you name it. Maybe I am missing the entire idea behind your goals :) Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 15:22 To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215218 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
Two reasons: 1) Because MM does not want to continue to invest in developing WDDX unless there is a substantial deman from its client base. I know this for fact beause I inquired about it. 2) I asked everyone here a couple of months ago if the OpenWDDX effort should be restarted and the consensus was the WDDX was fine in its current state. Rey... Calvin Ward wrote: Yes, but a query will have a consistent xml structure that can then be consistently accessed by JS (think WDDX). I think that's what folks are after. I'm not entirely sure why WDDX isn't being talked about more in regards to AJAX... -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 10:50 AM To: CF-Talk Subject: RE: Ajax and CFCs What type of structured data? The only thing you need to pass is XML. A CFML Struct can be serialized into a XMLDocument, and the same counts for Arrays, Lists, Queries, etc. you name it. Maybe I am missing the entire idea behind your goals :) Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 15:22 To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215221 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
The amount of consistency is in the hands of the developer. It just is about documenting the format. Do you have a situation where you problem appears? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 15:57 To: CF-Talk Subject: RE: Ajax and CFCs Yes, but a query will have a consistent xml structure that can then be consistently accessed by JS (think WDDX). I think that's what folks are after. I'm not entirely sure why WDDX isn't being talked about more in regards to AJAX... -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 10:50 AM To: CF-Talk Subject: RE: Ajax and CFCs What type of structured data? The only thing you need to pass is XML. A CFML Struct can be serialized into a XMLDocument, and the same counts for Arrays, Lists, Queries, etc. you name it. Maybe I am missing the entire idea behind your goals :) Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 augustus 2005 15:22 To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 7:28 AM To: CF-Talk Subject: Re: Ajax and CFCs On Monday 15 August 2005 20:12, Jim Davis wrote: 2) Passing structured data once you access them. It's the second bit that gets confusing as hell. It's trival to write toXML() methods on all your objects. MM even have a query2xml on DevNet. People that say things are trivial annoy me. ;^P It IS trivial on the server-side - not so trivial on the client side. Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. Again (and again and again) what we really need is a decent client-side parser for common formats. The only truly common format right now is SOAP-based web services (although they're still flaky as hell). IF you had such a library, completely client-side, you could instantly (in theory) consume web services from nearly all major server-side packages - most with little to now extra coding. What we really need is a rich, client-implementable _standard_ for transmission of structured data over HTTP. Something that (I think) needs to be a little more complex than JSON but not as complex as SOAP. Something like WDDX could have fit well... but it seems to have withered on the vine. Jim Davis ~| 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:215222 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
RE: Ajax and CFCs
-Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 10:50 AM To: CF-Talk Subject: RE: Ajax and CFCs What type of structured data? The only thing you need to pass is XML. A CFML Struct can be serialized into a XMLDocument, and the same counts for Arrays, Lists, Queries, etc. you name it. Of course they can - and everybody does it differently. XML isn't a panacea - used as it is by many today it's no better than a delimited list - in other words a one-off solution. WDDX has one method, JSON (tho' not XML) has another, SOAP a third (actually SOAP has at least nine or 10 ways to pass things if you leave the CF world). Of course you're also forgetting the client-side. Even tho' most of these methods use XML to send data TO the client they nearly all fall back on hackneyed manual parsing to send data FROM the client. We've got pipe-delimited lists, comma-delimited lists, underscore-delimited lists and every other kind of delimited list you could want. We've got hordes of special form fields and quasi XML. And none of this works with any of the rest of it even tho' every single one is solving the EXACT same problem of passing structured over a text transport. I really think for AJAX to truly take off there needs to be a standard method for this. SOAP was the promise - but it's bogged down in complexity. JSON has the right idea but is really too simple. In short I think we need: 1) A standard which, at the very least, defines text representations of arrays, objects, strings, nulls, dates, numbers and Booleans. It should, of course, allow for complex nesting of these types when applicable. 2) A method for validating such conversions. Unlike SOAP I think the standard should be locked down and define EXACTLY what it means when it says object or Array to prevent splintering. This is where JSON fails, in my opinion: it supports only JS literals (so there's no data typing beyond object and array) 3) A purely client-side (JavaScript) library for BOTH serializing and deserializing this standard. You should be able to convert any JS object to this with no help from the server. The SAME transport mechanism should be used for communication both TO and FROM the server - not XML down and delimited form-field content up as we see with most solutions today. 4) Support for the standard for major server-side packages. There's nothing that I've found that does this yet. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215227 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
RE: Ajax and CFCs
-Original Message- From: Rey Bango [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:11 AM To: CF-Talk Subject: Re: Ajax and CFCs Two reasons: 1) Because MM does not want to continue to invest in developing WDDX unless there is a substantial deman from its client base. I know this for fact beause I inquired about it. 2) I asked everyone here a couple of months ago if the OpenWDDX effort should be restarted and the consensus was the WDDX was fine in its current state. Personally I disagree when it comes to cross-server support. Its support in CF may be fine, but the rest of the libraries are nasty. The JS library, in particular is truly aged at this point. ;^) But WDDX is definitely the kind of solution I've been ranting about: something less complex than SOAP, but more complex than JSON which allows structured data to be passed to AND from JavaScript in a standardized way. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215228 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
Re: Ajax and CFCs
Well, if enough people are interested, I'll go back to the powers that be and see if they're interested in restarting it. Cranking up OpenWDDX.org again would be easy. MM has to make that call. Rey... Jim Davis wrote: -Original Message- Personally I disagree when it comes to cross-server support. Its support in CF may be fine, but the rest of the libraries are nasty. The JS library, in particular is truly aged at this point. ;^) But WDDX is definitely the kind of solution I've been ranting about: something less complex than SOAP, but more complex than JSON which allows structured data to be passed to AND from JavaScript in a standardized way. Jim Davis -- http://www.ReyBango.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215231 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
RE: Ajax and CFCs
\ -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:12 AM To: CF-Talk Subject: RE: Ajax and CFCs The amount of consistency is in the hands of the developer. It just is about documenting the format. You're thinking too small here, Micha. We're not saying we can't get the job done - this isn't a help me get this out the door issue. It's a broader question. Why should such a fundamental thing as passing structured data be left completely to individual implementation? Why should that implementation be tightly coupled to the solution built? Why shouldn't my interface be able to switch from obtaining data from CF to obtaining data from WebSphere without having to rebuild the transport mechanism on WebSphere? The complaint (well... my complaint) is that this is such a low level issue. Passing structured data from a server to a client needs to be solved by EVERY SINGLE person doing AJAX style applications. Yet we have hundreds if not thousands of incompatible solutions. When you see that doesn't it at least indicate to you that a useful umbrella standard would be a useful thing? Again, it's not that it can't be done or that doing a one-off or a personal standard is difficult. It's that the situation is screaming for a clear, widely-adoptable standard. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215232 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On Tuesday 16 August 2005 15:21, Jim Davis wrote: Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. This is true. However, it is hard to be generic and fast. THe Faces4Laszlo project over on IBM's alphaworks does something like building a javascript client-side representation of server side state, apperently, but I've not looked at it. -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215233 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
On Tuesday 16 August 2005 15:56, Calvin Ward wrote: I'm not entirely sure why WDDX isn't being talked about more in regards to AJAX... Because it's slow (client side) and heavy (libraries, and produced WDDX strings). -- Tom Chiverton Advanced ColdFusion Programmer ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215234 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:34 AM To: CF-Talk Subject: Re: Ajax and CFCs On Tuesday 16 August 2005 15:21, Jim Davis wrote: Also it's trivial to write _A_ packet on the server and _A_ consumer on the client for that one packet... but as you build more and more one-offs it gets less and less trivial. This is true. However, it is hard to be generic and fast. I could honestly care less about speed about this point. You have to have the capability first - then you can complain about how slow it is. ;^) But when talking about just client-side XML I really don't see an argument that serilziation/deserialization for a custom XML packet is any slower or faster than for a generic one. And once that's done you're dealing with native objects which are quick-as-you-please. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215246 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
RE: Ajax and CFCs
-Original Message- From: Thomas Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 11:35 AM To: CF-Talk Subject: Re: Ajax and CFCs On Tuesday 16 August 2005 15:56, Calvin Ward wrote: I'm not entirely sure why WDDX isn't being talked about more in regards to AJAX... Because it's slow (client side) and heavy (libraries, and produced WDDX strings). It's no slower than any other XML standard. The currently available code however - well damn, buddy - that's 6 years old! There's the standard JS parser available which is optimized for Netscape 3 and an experimental one optimized for the new IE 4.0 browser. The standard isn't at fault for the speed problems, I think, it's the code that supports it. But even with that old code WDDX on the client is pretty damn peppy on any modern browser/machine just due to improvements in the environment. The standard is verbose... but that's less a problem now than ever before as well. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215250 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
RE: Ajax and CFCs
WebORB uses proprietary internal BlueDragon APIs to invoke CFCs directly (we worked very closely with the WebORB developers to make this work). I suppose it could be made to work with CFMX in a similar manner, but so far the WebORB developers have chosen not to do so. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Andrew Grosset [mailto:[EMAIL PROTECTED] Sent: Sunday, August 14, 2005 8:43 PM To: CF-Talk Subject: Re: Ajax and CFCs Very impressive demo, I found it here: http://blog.newatlanta.com/weborb/examples/richclientprimer/ja vascript-ajax/phonebook-bluedragon.cfm curious as to why it can't be made to work under CFMX? !! :) Andrew WebORB 2.0 is a commercial product that includes a JavaScript/AJAX library that lets you invoke CFCs (and other server-side objects and services) from JavaScript: http://www.themidnightcoders.com/weborb/aboutWeborb.htm CFC support only works with BlueDragon, not CFMX. BlueDragon is not required to invoke other server-side objects and services (Java objects, .NET objects, web services, etc.). WebORB also enables Flash Remoting for BlueDragon. There are live demos of WebORB on my blog: http://blog.newatlanta.com/index.cfm?mode=entryentry=A49151F 3-CC13-10D 9-CF9 78A54402ECFEE Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214966 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
RE: Ajax and CFCs
Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214967 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214968 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| 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:214973 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
I don't understand why weborb is needed at all. Last I checked CFMX supported HTTP GET and POSTs. mike chambers [EMAIL PROTECTED] Vince Bonfanti wrote: WebORB uses proprietary internal BlueDragon APIs to invoke CFCs directly (we worked very closely with the WebORB developers to make this work). I suppose it could be made to work with CFMX in a similar manner, but so far the WebORB developers have chosen not to do so. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Andrew Grosset [mailto:[EMAIL PROTECTED] Sent: Sunday, August 14, 2005 8:43 PM To: CF-Talk Subject: Re: Ajax and CFCs Very impressive demo, I found it here: http://blog.newatlanta.com/weborb/examples/richclientprimer/ja vascript-ajax/phonebook-bluedragon.cfm curious as to why it can't be made to work under CFMX? !! :) Andrew WebORB 2.0 is a commercial product that includes a JavaScript/AJAX library that lets you invoke CFCs (and other server-side objects and services) from JavaScript: http://www.themidnightcoders.com/weborb/aboutWeborb.htm CFC support only works with BlueDragon, not CFMX. BlueDragon is not required to invoke other server-side objects and services (Java objects, .NET objects, web services, etc.). WebORB also enables Flash Remoting for BlueDragon. There are live demos of WebORB on my blog: http://blog.newatlanta.com/index.cfm?mode=entryentry=A49151F 3-CC13-10D 9-CF9 78A54402ECFEE Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215002 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
RE: Ajax and CFCs
I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215005 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
RE: Ajax and CFCs
I agree, it seems like the performance would be much better to invoke the calls directly from the application server, especially as the application and the client already natively understand each other... -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free
RE: Ajax and CFCs
WebORB performs that same function as CF's built-in Flash gateway, except that it does it for both Flash and JavaScript/AJAX clients, and supports a variety of server-side objects other than just CFCs (see their architecture diagram that I provide a link to below). Vince -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis
RE: Ajax and CFCs
CFCs can be invoked directly through the XMLHttpRequest object as long as the CFC support remote access. I tend to cache my components and access them through a controller/proxy which can also be easily done via Ajax. And finally, you can easily call CFM pages directly which return either HTML or XML (the XMLHttpRequest object supports both). You don't need any third-party products. Ajax and ColdFusion go very well together as-is. You can see an example of integration here: http://weblogs.macromedia.com/mxna/reports/categoryFeedReport/index.cfm Christian Hi, Do you know any example on how to integrate an AJAX web interface with ColdFusion Components? Do you know any good AJAX client/server library with ColdFusion support? ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215025 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
CF's built-in Flash gateway *is* a middle tier, just like WebORB. And, no, you probably wouldn't want to use WebORB to invoke CFCs on CFMX (assuming it's even possible). Vince -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 2:41 PM To: CF-Talk Subject: RE: Ajax and CFCs I agree, it seems like the performance would be much better to invoke the calls directly from the application server, especially as the application and the client already natively understand each other... -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else
Re: Ajax and CFCs
Why is weborb even in this conversation? mike chambers [EMAIL PROTECTED] Vince Bonfanti wrote: CF's built-in Flash gateway *is* a middle tier, just like WebORB. And, no, you probably wouldn't want to use WebORB to invoke CFCs on CFMX (assuming it's even possible). Vince -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 2:41 PM To: CF-Talk Subject: RE: Ajax and CFCs I agree, it seems like the performance would be much better to invoke the calls directly from the application server, especially as the application and the client already natively understand each other... -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation
Re: Ajax and CFCs
ColdFusion can also support requests from Flash and JavaScript / AJAX. I still don't see what you would want to install another server element just to do some simple JavaScript to ColdFusion communication. mike chambers [EMAIL PROTECTED] Vince Bonfanti wrote: WebORB performs that same function as CF's built-in Flash gateway, except that it does it for both Flash and JavaScript/AJAX clients, and supports a variety of server-side objects other than just CFCs (see their architecture diagram that I provide a link to below). Vince -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis
Re: Ajax and CFCs
Why is weborb even in this conversation? mike chambers [EMAIL PROTECTED] Vince Bonfanti wrote: CF's built-in Flash gateway *is* a middle tier, just like WebORB. And, no, you probably wouldn't want to use WebORB to invoke CFCs on CFMX (assuming it's even possible). Vince ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215033 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
So WebORB is nothing more than a facade? I'm still curious as to why you would need this type of architecture. It seems pointless to have a facade when you have an xml standard that is providing the same benefits. (ie. the ability to convert your backend from CF to .NET without interfering with the front end). -Adam On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: WebORB performs that same function as CF's built-in Flash gateway, except that it does it for both Flash and JavaScript/AJAX clients, and supports a variety of server-side objects other than just CFCs (see their architecture diagram that I provide a link to below). Vince -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems
Re: Ajax and CFCs
The Flash Gateway provides a binary communication stream between the flash player and a backend server. But a browser can already natively get XML from a backend server, so whats the point of adding a gateway in between them? -Adam On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: CF's built-in Flash gateway *is* a middle tier, just like WebORB. And, no, you probably wouldn't want to use WebORB to invoke CFCs on CFMX (assuming it's even possible). Vince -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 2:41 PM To: CF-Talk Subject: RE: Ajax and CFCs I agree, it seems like the performance would be much better to invoke the calls directly from the application server, especially as the application and the client already natively understand each other... -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF
RE: Ajax and CFCs
Not to mention the added cost. Isn't part of the value of ColdFusion the integrated solutions such as Flash Remoting, Verity, Web Services, etc.? - Calvin -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 2:56 PM To: CF-Talk Subject: Re: Ajax and CFCs The Flash Gateway provides a binary communication stream between the flash player and a backend server. But a browser can already natively get XML from a backend server, so whats the point of adding a gateway in between them? -Adam On 8/15/05, Vince Bonfanti [EMAIL PROTECTED] wrote: CF's built-in Flash gateway *is* a middle tier, just like WebORB. And, no, you probably wouldn't want to use WebORB to invoke CFCs on CFMX (assuming it's even possible). Vince -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 2:41 PM To: CF-Talk Subject: RE: Ajax and CFCs I agree, it seems like the performance would be much better to invoke the calls directly from the application server, especially as the application and the client already natively understand each other... -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:27 PM To: CF-Talk Subject: RE: Ajax and CFCs I'm a little foggy on why I'd call a middle tier like WebORB to handle my web service calls when I can easily use CF's built in Flash gateway or open source AMF-based alternatives? Cheers, Kevin -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: August 15, 2005 8:21 AM To: CF-Talk Subject: RE: Ajax and CFCs I think it helps to understand the WebORB architecture, which is best explained on their web site: http://www.themidnightcoders.com/weborb/aboutWeborb.htm WebORB is first of all a server (its full name is WebORB Presentation Server) that acts as a gateway or broker that allows rich clients (Flash or JavaScript/AJAX) to invoke server-side objects. In the case of JavaScript/AJAX, WebORB allows clients to use a single protocol--implemented by the WebORB Rich Client System--to invoke a variety of server-side objects. Once you realize it's the WebORB server that's actually invoking CFCs (on behalf of the client), and not the client invoking CFCs directly, then it should be clear that invoking the CFCs on BlueDragon directly makes more sense than invoking them via web services. It doesn't make sense to use web services protocols to invoke objects that reside on the same local server--the performance is much better to invoke them directly. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Micha Schopman [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 9:34 AM To: CF-Talk Subject: RE: Ajax and CFCs Vince, Have there been any specific reasons you know of for taking such a proprietary approach or was it mainly aimed towards best performance because of its close integration? Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 -- -- -- -- - Modern Media, Making You Interact Smarter. Onze oplossingen verbeteren de interactie met uw doelgroep. Wilt u meer omzet, lagere kosten of een beter service niveau? Voor meer informatie zie www.modernmedia.nl -- -- -- -- - -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: maandag 15 augustus 2005 13:33 To: CF-Talk Subject: RE: Ajax and CFCs Jim, The WebORB implementation doesn't use SOAP or web services to invoke CFCs on BlueDragon--instead, WebORB invokes them directly via BlueDragon's internal APIs. Also, WebORB works with both the Java/J2EE and .NET editions of BlueDragon. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 1:04 AM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript
RE: Ajax and CFCs
I feel like the point has been lost here. There are two issues at question: 1) Accessing (connecting, consuming, whatever) web services via the client (presumably via JavaScript). 2) Passing structured data once you access them. EVERYTHING can do the first. It's easy to call CFCs (whether on CF or BD), ..NET services, etc using the client. Simple. You can pass structured form fields (which is what CFAJAX and it looks like WebOrb does). It's the second bit that gets confusing as hell. There are lots of options to do this and all essentially do the same thing: convert structured data to text and back. It's a shame however that there's not more cross-platform support for SOMETHING. JSON has a lot of support, but it's relatively weak (it has no concept of data typing for example) compared to others. WDDX still works... but it's been YEARS since it's had any sort of work done on it. People don't want to use 5 year old Objects for mission-critical stuff. There are dozens if not hundreds of custom solutions using structured form fields. Many of these return raw JavaScript code (CFAJAX and CFWDDX do this) instead of truly allowing the client to parse the information. SOAP was supposed to be the way to go, the wave of the future - but the client-side support is pitiful and buggy as hell when it comes to cross-platform consumption. I can find a JS libraries that support single servers, but nothing general because each server absolutely knows that's it's way of describing data is the best and only way. So you're stuck with a nice easy way in JavaScript to get a blob of text from a server but very little to help you from that point on - especially if you don't want to be tied to a single server. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215040 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
RE: Ajax and CFCs
Thanks, Jim. That's exactly what WebORB does--makes it easy to handle structured data return from a CFC within your JavaScript. Take a look again at the example on my blog (the JavaScript source code is all there) and see how easy it is to process a query variable returned from a CFC: http://blog.newatlanta.com/weborb/examples/richclientprimer/javascript-ajax/ phonebook-bluedragon.cfm WebORB makes handling the other CFML complex types (arrays and structs) just as easy. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 3:13 PM To: CF-Talk Subject: RE: Ajax and CFCs I feel like the point has been lost here. There are two issues at question: 1) Accessing (connecting, consuming, whatever) web services via the client (presumably via JavaScript). 2) Passing structured data once you access them. EVERYTHING can do the first. It's easy to call CFCs (whether on CF or BD), ..NET services, etc using the client. Simple. You can pass structured form fields (which is what CFAJAX and it looks like WebOrb does). It's the second bit that gets confusing as hell. There are lots of options to do this and all essentially do the same thing: convert structured data to text and back. It's a shame however that there's not more cross-platform support for SOMETHING. JSON has a lot of support, but it's relatively weak (it has no concept of data typing for example) compared to others. WDDX still works... but it's been YEARS since it's had any sort of work done on it. People don't want to use 5 year old Objects for mission-critical stuff. There are dozens if not hundreds of custom solutions using structured form fields. Many of these return raw JavaScript code (CFAJAX and CFWDDX do this) instead of truly allowing the client to parse the information. SOAP was supposed to be the way to go, the wave of the future - but the client-side support is pitiful and buggy as hell when it comes to cross-platform consumption. I can find a JS libraries that support single servers, but nothing general because each server absolutely knows that's it's way of describing data is the best and only way. So you're stuck with a nice easy way in JavaScript to get a blob of text from a server but very little to help you from that point on - especially if you don't want to be tied to a single server. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215043 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 3:37 PM To: CF-Talk Subject: RE: Ajax and CFCs Thanks, Jim. That's exactly what WebORB does--makes it easy to handle structured data return from a CFC within your JavaScript. Take a look again at the example on my blog (the JavaScript source code is all there) and see how easy it is to process a query variable returned from a CFC: http://blog.newatlanta.com/weborb/examples/richclientprimer/javascript- ajax/ phonebook-bluedragon.cfm WebORB makes handling the other CFML complex types (arrays and structs) just as easy. Yup - for CF types. And that's not even remotely a bad thing. CFAjax works wonderfully in the same scenario as well. If you can control both the client and the server any number of solutions will work great. It's when you want a client-side application to accept data from a CFC, a ..NET service, a PERL service and a Java service that things start to get ridiculous. JSON works across implementations (Java, PERL, Python, JavaScript, CF, etc) because its implementation is so very, very simple. But it lacks all support for non-native JS objects and doesn't actually support many native objects (like Dates). We're down to the point where if you want something cross platform you're stuck with non-trivial task of writing it yourself or accepting severe compromises... and this far into the game it seems ridiculous that this should be the case. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215047 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
I don't know anything at all about JSON, so I can't comment. But, I think WebORB does exactly the same thing for invoking Java objects, ..NET objects, web services, etc. as it does for CFCs; it converts the complex types into something that's easily and consistently managed by your JavaScript. You really should take a look at it. Vince -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 3:51 PM To: CF-Talk Subject: RE: Ajax and CFCs -Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 3:37 PM To: CF-Talk Subject: RE: Ajax and CFCs Thanks, Jim. That's exactly what WebORB does--makes it easy to handle structured data return from a CFC within your JavaScript. Take a look again at the example on my blog (the JavaScript source code is all there) and see how easy it is to process a query variable returned from a CFC: http://blog.newatlanta.com/weborb/examples/richclientprimer/javascript - ajax/ phonebook-bluedragon.cfm WebORB makes handling the other CFML complex types (arrays and structs) just as easy. Yup - for CF types. And that's not even remotely a bad thing. CFAjax works wonderfully in the same scenario as well. If you can control both the client and the server any number of solutions will work great. It's when you want a client-side application to accept data from a CFC, a ..NET service, a PERL service and a Java service that things start to get ridiculous. JSON works across implementations (Java, PERL, Python, JavaScript, CF, etc) because its implementation is so very, very simple. But it lacks all support for non-native JS objects and doesn't actually support many native objects (like Dates). We're down to the point where if you want something cross platform you're stuck with non-trivial task of writing it yourself or accepting severe compromises... and this far into the game it seems ridiculous that this should be the case. Jim Davis ~| 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:215051 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: Vince Bonfanti [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 3:59 PM To: CF-Talk Subject: RE: Ajax and CFCs I don't know anything at all about JSON, so I can't comment. But, I think WebORB does exactly the same thing for invoking Java objects, ..NET objects, web services, etc. as it does for CFCs; it converts the complex types into something that's easily and consistently managed by your JavaScript. You really should take a look at it. But you've already said it's a server-side solution or did I make that up (it's been known to happen)? Although I'm sure it's incredibly useful to many for current purposes there should be no server-side footprint. CF and BD already do SOAP-based services via CFC, .NET does them automatically as well. WebSphere has built-in thingies. The best solution would be to consume these native services with client-side code. As it is most solutions (including WebORB, I believe) force the install of a server-side component which work ONLY with their client components (which, of course, work ONLY with their server-side component). It's a client-side solution that's (very) tightly coupled with a server-side solution. The loosely coupled model of WDDX is much more attractive to me. Define a method of transfer and promote other implementations of it. As long as I follow the specification I can use an off-the-shelf tool, build my own or whatever. This was the promise of SOAP... but it went south pretty damn quick with lots of complexity and not nearly the compatibility that was promised. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215054 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
I'm thinking that saying you don't need this in between... is like saying that you don't need CF or any other scripting language because you could build everything you want in 1's and 0's. I know that's a bit of an extreme oversimplification, but I also see the value in a utility that makes it easier for people to accomplish a certain goal. I've got no doubts that we could all work out how to pass the structures back and forth if we worked on it long enough, but CFAJAX, Weborb, OpenRico, Neuromancer... are all available alternatives to make it easier to do it. What's so offensive about that? --Ferg ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215056 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
Did you Google CFAJAX yet? -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Sunday, August 14, 2005 6:21 AM To: CF-Talk Subject: Ajax and CFCs Hi, Do you know any example on how to integrate an AJAX web interface with ColdFusion Components? Do you know any good AJAX client/server library with ColdFusion support? Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214938 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: Ajax and CFCs
-Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Sunday, August 14, 2005 7:21 AM To: CF-Talk Subject: Ajax and CFCs Hi, Do you know any example on how to integrate an AJAX web interface with ColdFusion Components? Do you know any good AJAX client/server library with ColdFusion support? There are a few options. JSON offers good support for both CF and JavaScript (albeit not in a single library). Neuromancer is pretty feature rich and offers all the connectivity you might need (its a tad on the complex side for my tastes, but correspondingly more powerful than many options). WDDX is old and really needs to be updated, but it does pretty much everything a growing AJAX app needs. Remember however that all of these essentially boil down to a single problem solved: passing structured data (javascript objects, complex structs, etc) over a text-only transport (http). ALL of them provide a method to convert complicated stuff to text and back again. I strongly suggest that you design your system in such a way as to hide and abstract the transport mechanism as much as possible. You should, in other words, be able to switch from JSON to WDDX with little problem - both do (essentially) the same thing so why should there be any application dependencies on them beyond the transfer of data? Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214944 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
RE: Ajax and CFCs
WebORB 2.0 is a commercial product that includes a JavaScript/AJAX library that lets you invoke CFCs (and other server-side objects and services) from JavaScript: http://www.themidnightcoders.com/weborb/aboutWeborb.htm CFC support only works with BlueDragon, not CFMX. BlueDragon is not required to invoke other server-side objects and services (Java objects, .NET objects, web services, etc.). WebORB also enables Flash Remoting for BlueDragon. There are live demos of WebORB on my blog: http://blog.newatlanta.com/index.cfm?mode=entryentry=A49151F3-CC13-10D9-CF9 78A54402ECFEE Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com -Original Message- From: wolf2k5 [mailto:[EMAIL PROTECTED] Sent: Sunday, August 14, 2005 7:21 AM To: CF-Talk Subject: Ajax and CFCs Hi, Do you know any example on how to integrate an AJAX web interface with ColdFusion Components? Do you know any good AJAX client/server library with ColdFusion support? Thanks. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214954 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
Re: Ajax and CFCs
Very impressive demo, I found it here: http://blog.newatlanta.com/weborb/examples/richclientprimer/javascript-ajax/phonebook-bluedragon.cfm curious as to why it can't be made to work under CFMX? !! :) Andrew WebORB 2.0 is a commercial product that includes a JavaScript/AJAX library that lets you invoke CFCs (and other server-side objects and services) from JavaScript: http://www.themidnightcoders.com/weborb/aboutWeborb.htm CFC support only works with BlueDragon, not CFMX. BlueDragon is not required to invoke other server-side objects and services (Java objects, .NET objects, web services, etc.). WebORB also enables Flash Remoting for BlueDragon. There are live demos of WebORB on my blog: http://blog.newatlanta.com/index.cfm?mode=entryentry=A49151F3-CC13-10D9-CF9 78A54402ECFEE Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214957 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: Ajax and CFCs
There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. mike chambers [EMAIL PROTECTED] Andrew Grosset wrote: Very impressive demo, I found it here: http://blog.newatlanta.com/weborb/examples/richclientprimer/javascript-ajax/phonebook-bluedragon.cfm curious as to why it can't be made to work under CFMX? !! :) Andrew WebORB 2.0 is a commercial product that includes a JavaScript/AJAX library that lets you invoke CFCs (and other server-side objects and services) from JavaScript: http://www.themidnightcoders.com/weborb/aboutWeborb.htm CFC support only works with BlueDragon, not CFMX. BlueDragon is not required to invoke other server-side objects and services (Java objects, .NET objects, web services, etc.). WebORB also enables Flash Remoting for BlueDragon. There are live demos of WebORB on my blog: http://blog.newatlanta.com/index.cfm?mode=entryentry=A49151F3-CC13-10D9-CF9 78A54402ECFEE Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214962 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
RE: Ajax and CFCs
-Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:51 AM To: CF-Talk Subject: Re: Ajax and CFCs There is nothing there that couldn't be done with CFMX (or any other server language). It is a simple request / response using AJAX. JavaScript sends data to ColdFusion, ColdFusion sends a response back, JavaScript updates the page. My guess (nothing more) is that it the same problem that other SOAP implementations have: they don't like each other. MS implementations work great with .NET service but bomb on CFMX services for example. CF implementations work great in some places and blow up in others... In my experience these problems, once dug out, are pretty small - but that doesn't matter because it seems the implementers don't really care all that much - it works for what they want it to work with and everybody else can just toe the line or use something else. It's also very likely (because SOAP isn't all that simple) that they're using some off-the-shelf implementation inside this thing. And if that implementation doesn't support CF SOAP/WSDL then this thing won't. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214963 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=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
