On 2/21/07, Dave Watts <[EMAIL PROTECTED]> wrote: > > > 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?"
Ou contrare, or however you spell it. "Per field editing" is relevant to a "per field" modification history. Didn't I mention that, w/AJAX (or vice versa ;)? > 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. Are you sure? You're the man, so I wouldn't presume to know more about tuning CF- but I could have sworn I saw somewhere that you could "tune" your server for such things. Am I mistaken? And, as I've stated before, we're assuming we're NOT exchanging the same amount of data in the long run. As I've previously stated, how often do you update every field in a record? Really need that whole navigation menu again?-- etc. Sure, we can depend on the client's cache, but that leads to a whole other set of problems (yes, the nature of the beast-- request based...). 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 And here we get into the realm of "the data itself can dictate UI", which is pretty cool. You can't edit a record without editing a field. But anyways, what I was saying was perhaps the /type of record/ dictates that saving "per field" is OK, and perhaps expected. PERHAPS, and this is getting far fetched, but perhaps you could set a field to retain a "history" of all edits, sorta like a log, and kinda zip through them right there, inline, and revert or do whatever you want? Just for that field? Sound crazy? Over the top? Perhaps. (damn, now I messed up that Doris Day song ref-- it only had 3 ;) 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. The really awesome thing about ORM, is that you're dealing with objects, not so much database tables. Well, they're sorta DB tables, but abstracted, so you can do nifty things like actually save the object when you want, or whatnot. Putting off saving for a bit, till they're sure, is a possibility, I think. Assuming we're not working on the idea that the user knows to expect field level editing. ;) > 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. This is totally off topic, but I actually think that you can define the terms of art used. I'm totally haphazard and half-assed, so I hope I'm not responsible for it, but I'm pretty sure it's doable. 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. Nonsense. Load is load is load. And, theoretically, if you can refrain from sending extraneous data, you'll have less data to send. Theoretically, I've not practiced it much. =)) But anyways, are you telling me that when a "normal" HTML type app is under load, and a user clicks that submit button, and the page just sorta hangs there-- that's better than the nifty little AJAX spinnie "working" widgets that appear instantly when you click that button, no matter how long that request will take? When you perform any action, actually? "Hey, look, I can tell when the app is thinking! Nifty!" > 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. Well, I've had the most experience with Dojo, and believe it or not, they've actually thought of this stuff. There're hooks for whatever you need. Did the request error? Did it time out? Do you need a custom error? Custom "loading/processing" message? It's really thought out, actually. (Did I mention there's "Advice"!) Personally, I like the immediate response far better than the one I have to initiate, but I like computers, and techie type thingies, and less work, more play, etc., etc.. UI is often overlooked, and it really shouldn't be. :D -- "What is time, but smaller parts of time?" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 by Adobe® Dyncamically transform webcontent into Adobe PDF with new ColdFusion MX7. Free Trial. http://www.adobe.com/products/coldfusion Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:270425 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
