New Ajax examples?

I'm managing a young off-site programmer who needs some interesting projects after he launches this next app by the end of the week.  I'd like to give him a few cookbook recipes on buiulding Ajax form interactions.  I've pointed him to Sajax and CFAjax over the summer, but I think he needs something simpler.   Problem is my hands are full with some other projects and I can't surf. Anyone recommend something for a newbie?  Anyone read the new Ajax books?  Any worth getting? thanks, Don

Actually, I have just put out an AJAX/ColdFusion API that is EXTREMELY simple...... Have your programmer (and everyone) check it out. For lack of anything more creative I am simply calling it JSMX (JavaScript MX). But the learning curve is "minutes". You can learn about it and download it at: http://www.lalabird.com/jsmx/ HTH, Todd ----- Excess quoted text cut - see Original Post for more -----

Todd, this looks interesting. Thanks for sharing. I can report that it works fine with BlueDragon, if anyone is interested. :-) As for your list of http sniffers, I'll recommend another: Fiddler, from MS http://www.fiddlertool.com/Fiddler/help/?ver=1.1.0.1 Finally, can I make a suggestion about the sample? In its readme.txt, could you add the clarification that one must have also implemented the engine.js? I realize you point it out on the web page, but you know how people tend to miss that. Indeed, I wonder why you don't just go ahead and bundle the engine.js, since it is indeed required and the code is written to presume that it's found in the same directory as all the other code. Charlie Arehart CTO, New Atlanta Communications, makers of BlueDragon (678) 256-5395 charlie@newatlanta.com www.newatlanta.com/bluedragon/ ----- Excess quoted text cut - see Original Post for more -----

Charlie, Thanks for the input (and testing it with BlueDragon). Re: engine.js and the bundle: Originally I had done just that. But I was making soooo many little tweaks to it that I kept having to resave the .zip so I just pulled it out ;) But, you are right and since I am not really changing the file anymore I will "re-bundle" it. Re: your sniffer suggestion. I'll certainly add it to the list. Thanks again. ----- Excess quoted text cut - see Original Post for more ----- ----- Excess quoted text cut - see Original Post for more -----

"The main difference between this and every other AJAX implimentation is that JSMX does not use XML to pass data between the server and the client (browser)." Apart from CFAJAX, which works in an almost identical way to this, passing raw javascript around rather than XML. > Actually, > > I have just put out an AJAX/ColdFusion API that is EXTREMELY simple...... Have your programmer (and everyone) check it out. For lack of anything more creative I am simply calling it JSMX (JavaScript MX). But the learning curve is "minutes". > > You can learn about it and download it at: http://www.lalabird.com/jsmx/ -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/

Personally I don't get the need for all the extra stuff that CFAjax and others hang on this.  This web site has the basic example: http://www.sitepoint.com/article/take-command-ajax Server side it uses PHP but you can obviously use anything.  Take it from there and run with it. I use it for deciding if a new user name is unique in our system before submitting the page.  I also populate drop down boxes with state names, if applicable, after the users country is selected.  CSS with Ajax is quite cool.  If the country doesn't use states/provinces or the like the text entry box doesn't even show up. Shawn I'm managing a young off-site programmer who needs some interesting projects after he launches this next app by the end of the week.  I'd like to give him a few cookbook recipes on buiulding Ajax form interactions.  I've pointed him to Sajax and CFAjax over the summer, but I think he needs something simpler.  Problem is my hands are full with some other projects and I can't surf. Anyone recommend something for a newbie?  Anyone read the new Ajax books? Any worth getting? thanks, Don

> Personally I don't get the need for all the extra stuff that CFAjax and > others hang on this.  This web site has the basic example: > http://www.sitepoint.com/article/take-command-ajax You could try http://rachaelandtom.info/journal.pl?op=display&uid=3&id=232 too. -- Tom Chiverton Advanced ColdFusion Programmer

Just curious as to why a developer would choose not to use XML to pass the data? Shawn McKee "The main difference between this and every other AJAX implimentation is that JSMX does not use XML to pass data between the server and the client (browser)." Apart from CFAJAX, which works in an almost identical way to this, passing raw javascript around rather than XML.

XML requires a JavaScript XML parser, overhead on the client end that may not be desired. Passing JavaScript (or even JSON) back to the browser means that this parsing step can be skipped. > Just curious as to why a developer would choose not to use XML to pass the > data? > -- CFAJAX docs and other useful articles: http://jr-holmes.coldfusionjournal.com/

How is passing the actual javascript better than passing back the actual content? I'm curious because we did a small project by passing XML, but it became a big project because of that. Now, I'm toying with the idea of passing back HTML and just setting the .innerHTML property where it needs to appear. If passing js, rather than HTML, is better for some reason, then I may switch to that method. Thanks M!ke XML requires a JavaScript XML parser, overhead on the client end that may not be desired. Passing JavaScript (or even JSON) back to the browser means that this parsing step can be skipped. > Just curious as to why a developer would choose not to use XML to pass > the data?

I was looking at the taconite framework this weekend and they pass the HTML back.  I really don't like this idea as you're service now has to know quite a bit about the user interface and if you want to use this interface from flash, you'll now have to parse the data out of an html response. I like passing data back either as json or xml.  There are several libraries that can make xml and/or json parsing easy.  I'll do either of these formats as they're easy to consume and platform agnostic. ----- Excess quoted text cut - see Original Post for more -----

The discussion on "what is the right thing to pass back" really becomes a matter of personal choice and also what you are trying to accomplish. I agree that XML is the most agnostic way of passing data back and forth. But if the only client you are ever going to send your data to is a JavaScript client, do you really need it to be agnostic? Of course as you pointed out if you are planning on sending data to both JavaScript and Flash (and maybe others), then definitely XML is the way to go. So looking at it from how I use AJAX, sending back JavaScript is the most efficient way for me to get my code written. From the CF side, I still use Structures and Arrays, so it is faster (development wise) for me to "WDDX/toScript()" it to JavaScript than loop it into an XML string. From the client side (strictly JavaScript) it is also quicker (development and latency wise) for me to "eval()" the JS string and run with it than it is to parse XML. Also, my JS strings tend to be slightly smaller then XML strings so there is also a bandwidth benefit (marginally). I suppose the bottom line is that AJAX as a rule is pretty cool and exciting and has a ton of potential.... so if a developer can find any API that works for them they should use it. If you feel that passing back JS is they way you want to go, then I think JSMX is a pretty easy way of doing it. And as James pointed out, JSMX is NOT the only one doing this, so I changed the website. Guess I'm not as much of a visionary as I thought ;) Cheers, -Todd ----- Excess quoted text cut - see Original Post for more -----

As for the JS vs. HTML discussion: Well, a JS API can do both. i.e. jsVar = "<ul><li>blah</li></ul>";. Many times I send back HTML (it's just a string) instead of Objects and Arrays. An example would be, I have found that CF is much more efficient in doing large loops then JS (I’m talking in the 100's). So, I'll tend to build up things like lists in CF and pass them back as HTML and use the .innerHTML approach. But, for populating a form I'll send back an Object() and let JS "fill in the blanks". However, passing nothing but HTML back can be a bit of AJAX "overuse" in my opinion. Sites that do not ever reload and just pass entire pages of HTML tend to have problems typical of, let's say, Flash sites. You break the back button, make it difficult for people to bookmark specific pages within your site, and practically prevent Search Engine Spidering. But, again that could be ok for a specific application, so I won’t say it’s always a bad idea. HTH, -Todd ----- Excess quoted text cut - see Original Post for more -----

Mike, besides the responses from Zaphod and Todd so far, let me clarify as well that I think the use of JS being described isn't *quite* the same as "passing back HTML". In the latter case, as you say, you're then just plunking the HTML onto the page, and as has been said some feel that's a blurring of the lines between presentation and logic. Rather, the notion of JS use being described here is more just as a means of packaging the data to be transmitted back and forth. Just as XML is one way (and indeed in the Flash world AMF is another), in this case the JS isn't presentational JS but instead is representing the data sent from the server in a JS way. That can then be processed on the browser (much like you may have processed XML before, but perhaps more easily) and then from it the presentation can be rendered (with DHTML on the browser, as one would do otherwise). One way to view it as a spectrum: on one end, one sends only XML and processes it on the browser; on the other, one sends HTML and shows it on the browser. In the middle, closer to the use of XML, one sends JS objects to represent the data (and in CF that can be created with WDDX, or using one of the JSON-based libraries). Hope that's helpful. Like so many subjects in computing, there are many ways to slice a cake, and simple solutions while appealing often lose flexibility, performance, reusability. One has to weigh all the pro's and con's. Many of these have been discussed often before with respect to passing data back and forth to the browser. It's just that Ajax has brought many people to the discussion again. It will take time for old lessons learned to be re-learned by the new crowd. Charlie Arehart CTO, New Atlanta Communications, makers of BlueDragon (678) 256-5395 charlie@newatlanta.com www.newatlanta.com/bluedragon/ ----- Excess quoted text cut - see Original Post for more -----