Really interesting, Frank. Thanks a million. Michael McGrady
Frank W. Zammetti wrote:
+1.
The thing that amazes me is that truly rich web-based clients can be done with nothing more than Javascript and DHTML, which to me is really optimal... you get all the best benefits of a web-delivered solution, but can get extremely fat-client-like look, feel and functionality.
Not to toot my own horn (not that I don't do that of course :) ), but... around the office I'm known as the guy that can make a web application that most users think is a classic fat-client. Literally, some users can't tell they are using a web-based application. I'm fortunate in that the higher-ups in my shop dictated IE-only (lucky in the sense that it's one browser to deal with, not in other ways of course)... the point being that as long as you target relatively recent browsers, really rich clients aren't as hard as they used to be in terms of multi-browser support.
I do a whole lot with frames-based designs, especially the idea of one of the frames being "hidden", which allows for caching of data, which allows for a lot of functionality with the server's input (i.e., sorting tables and such). Yes, you have to be careful with data consistency issues, but a good architecture deals with them. Most of the apps I do also open their own chromeless window, which relieves (or minimizes) many issues, like the back button (still can be done with keyboard shortcuts, but it's still something that can be dealt with).
I can't really push this approach for a generally-accessible web site, but if your talking internal applications where you have even some level of control over the clients touching your app, I'm surprised more people aren't taking this approach.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
