On 2/21/07, Dave Watts <@figleaf.com> wrote: .... > > AJAX is FAR from a "display" technology*. Far far far. > > > > But I do love my fancy fades and whatnot. :-) > > AJAX is not far from a display technology. That's all it is. It lets you > reorder your presentation logic in a way different from traditional HTML > application interfaces. This has nothing to do with fancy fades - > presentation logic builds your display, UI is display. It's what the user > sees, and interacts with.
Ah. I was thinking "display", as in static presentation of data, I guess. V.S. U.I, which sorta has a more "active" connotation for me. And there's absolutly nothing in your above example that requires (or even > has to do with) AJAX. You don't even need JavaScript at all to track > changes, you can do all that with basic HTML. You don't need AJAX to send > just the changed fields - I could write you an example of that using > JavaScript that would work in Netscape 2. 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. I can't deny that the new stuff far outshines like, having a button next to each field or some such. And an little bitty IFrame to return that fields status, I reckon. And finally, if you have to go back to the server for every individual field > edit, that's generally not going to scale well. And by "not well" I mean > "pretty awful". If you go back to the server for every individual field 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). edit, you have to assume that you won't get the results until after the > user's moved to the next field, so you'll have to address that in your > presentation logic. You will have to deal with the case where a user may 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. have several of these individual field edit requests that have been sent to > the server, and you're waiting for all of them to come back, unless you > synchronize the process in the display - there's that horrible word again, > sorry - by only allowing the user to edit one field at a time: forcing him > to wait for a response before allowing him to move to the next field. 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! =] > *this is one of my main issues with MVC "design"-- the UI can > > have a HUGE effect on the app-- huge! Hard to split > > everything into dispirit parts, ya know? Bah. Now that was > > a poor expression of whatever I meant. =-) > > I don't know why you put "design" in quotes there. The UI can certainly > have > an effect on how you write other tiers of your application, in that those > tiers will have to work with the UI you "develop". The entire point of MVC > is to minimize this effect, by decoupling the UI as much as possible. If > you're designing the other tiers of your application by asking yourself > "what can my UI do", you're asking for trouble. Exactly. "UI changes how you write your teirs", which, I keep getting the feeling, shouldn't be. At least from MVC, it seems like you should be able to just "swap" the "V" part out for a different one, which is just really hard to code for (at least for me- kinda a different way of thinking (Thank PP!)). Personally, I think "what can my UI do" is a HUGE (freaking HUGE) part of any application. That was my point, it's hard to keep it isolated or whatnot. It "effects" things (heh! what doesn't, neh? =). *Not* asking "what can my UI do" is also asking for trouble. Or at least not the best that can be/whatnot. \-= Love our chats, Dave! You're almost as cool as Nate. *grin* =-))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:270379 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
