> All AJAX is is JavaScript. It's not really something different. > XHTMLHTTPRequest stuff could have been done with frames/whatnot. > Or was done, I guess I'd stipulate.
You're missing my point, which is that AJAX is not, by itself, a relevant answer to the question, "how do I log database changes?" > Well, actually, I'd think, that if we stick to the idea that > usually when someone edits something it's one or two fields-- > isn't one or two fields far less data than, say 20 or so? Or > even 10? 5? > > Seems to me, that if thousands of folks went from pushing > 200k back and forth, to like 10k, or whatever, that would be > a Good Thing (assuming you've tuned your server for lots of > bitty requests). Unfortunately, there is no tunable parameter marked "lots of bitty requests". And, assuming that you're exchanging the same amount of data in the long run, AJAX doesn't have any overall effect on performance. However, it raises all sorts of problems that you don't have in a traditional linear HTML interface. Users edit records, not fields. That is, you wouldn't want to update each field when a user's entering data, because what if the user decides to discard his changes? What if another user wants to edit the same record? Are you seriously proposing field-level concurrency? Because that's going to suck. So, while you can validate each field in the interface, you will want to delay writing to the database until the user has done something to signal that he's finished changing that record. > See, it's terms like "presentation logic"-- presentation > doesn't scream UI at me. Seems more "static". And have you > seen how freaking fast this stuff is? You can have "as you > type" back and forth communication from the client to the > server, and it's instant! Sheesh. Freaks me out. > > Tons of tiny request tho. Tons of 'em. Since I don't define the terms of art used in the field of programming, there's not much I can do about them. And, again, it's fast enough from the users' perspective when it's not under load. When it is under load, you have a whole new set of problems that are pretty much AJAX-specific. > You make it seem like there is a delay between the editing > and the saving. > > You can do this stuff as the user types. Or every 2nd char, > whatever. > > Pretty much the opposite of what you're stating-- that it > slows the user down. > > Instead of having to submit the form to see if you've got > good data -adding mouse clicks and whatnot- you can do it > "real time". Amazing stuff! =] You're still making requests back to the server. It's not real time, any more than going from one page to the next is real time. It may often take less time than going from one page to the next, but if your server is under load, and it's busy, those AJAX requests will be queued just like any other HTTP requests. Your application, in order to work under load, will have to figure out how to deal with this situation. There are a few different strategies for this, but you have to use one or another of them to ensure correct performance under load. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create Web Applications With ColdFusion MX7 & Flex 2. Build powerful, scalable RIAs. Free Trial http://www.adobe.com/products/coldfusion/flex2/ Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:270399 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
