> Most JS libs worth their salt have in-line editing type deals > (where you're in a "view" and you click on a field, say the > "First Name" field, and it becomes a text-box so that you can > edit content)- aside from the first insert, how often is > /every/ field changed? That's the beauty of AJAX, or at > least part of it-- you only need to send the data you need. > > So basically, you handle every field edit (aside from the first > insert) individually. You can use nice little JS stuff that > instantly tells someone if they've entered a bad value (using > the server, mind- not client JS code) and whatnot. > > Since you're doing everything "piecemeal" soto speak, adding > a "logger" is a piece of cake. It's already broken down into > little bits, see. > > That's basically what I was thinking. > > 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. 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. 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 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 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. > *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. 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:270369 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
