Use AJAX for Bright and Shiny Web Apps

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Ralph, The use of AJAX methodology is something we're starting to implement here also. I think that it represents an exciting addition to any web based programming effort. chuck Opinions expressed are not necessarily those of my employer. "Ralph Daugherty" wrote in message news:6b3123f3.0@WebX.WawyahGHajS... > That was a great article from Duncan Kenzie! I'm looking forward to the > next installment on the AJAX black box approach for any web page. > > I have an older browser that doesn't implement the deviant HTTPRequest > method that Microsoft dreamed up to give their browser some necessary > semblance of a windows program, but I'm looking forward to installing > Firefox and checking out these AS/400 examples linked in the article since > Firefox, Konqueror, Opera, and Safari now support that deviant and > necessary semblance. > > I used HTTP to pass data in and out of the AS/400 five years ago but I > didn't use this method. On the other hand I was only in Chicago for the > day and had to dream up something on the spur of the moment. Glad Google > paved the way for a legitimate way to do it. > > rd

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
I think it's an exciting technology too - event driven fields on web pages interacting with the server, as long as the user doesn't hit REFRESH and expect the values to be preserved. Try http://www.weboggle.com to see AJAX in action. And check the links for that web master's comments on AJAX. Chris

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Ooops... wrong URL. Try these http://weboggle.shackworks.com/ http://weboggle.shackworks.com/about.html Chris

[D.Kenzie]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Chris, the Weboggle game is a great example of AJAX in action. Thanks. Regarding the refresh button - if your AJAX call updates the server-side database, then refreshing the page should call the server program again. You could program it in such a manner that it gets the values from the database if this is done. In other words, under some circumstances it is possible to retain the values a user enters even if the refresh key is clicked. Duncan

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Chirrs, Google Suggest is a simple example of how AJAX works and is a clear example for anyone who doesn't get it... http://www.google.com/webhp?complete=1&hl=en chuck Opinions expressed are not necessarily those of my employer. "Chris Ringer" wrote in message news:6b3123f3.2@WebX.WawyahGHajS... >I think it's an exciting technology too - event driven fields on web pages >interacting with the server, as long as the user doesn't hit REFRESH and >expect the values to be preserved. Try <http://www.weboggle.com> to see >AJAX in action. And check the links for that web master's comments on AJAX. > > Chris

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Yes, Chuck, I've seen that before, thanks. I was just giving weboggle some credit because this guy was using AJAX a year before Google. Chris

[Guest.Visitor]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Duncan, Yes, you sure could. You'd need to be more careful about storing information in the session object (IE: java servlets) because multiple AJAX requests could be competing now for the same session object. For example, you typed M and then I in a name search field and you only the stored the 'M' because the 'MI' request got processed first. These events don't necessarily run on the server in the same sequence in which they actually occurred in the UI. That's the nature of requests running asynchronously. But programming could handle this. Chris

[nandelin]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Thank you, Duncan, for this informative article. There have been a number of applications where targeting hidden frames with asynchronous requests has been helpful to me. www.zimbra.com has a demo of an email client that implements AJAX-like techniques, but may carry the idea to an extreme by implementing an extensive JavaScript based runtime engine. Not only does the application implement asynchronous requests in the background, but most of the user interface is implemented via client-side JavaScript, keeping requests to the server at a minimum. JavaScript then becomes the primary programming language, which has a lot of downsides from my perspective. Nathan Andelin

[nandelin]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
From my perspective, the Document Object Model is one of the most convoluted, poorly documented, misinterpreted, misunderstood interfaces in any development environment. It's implemented differently in different browsers. It's difficult for developers to master. JavaScript would be practically useless without it. JavaScript development is hampered by limited development tools, debuggers, and frameworks. A number of developers promote so called "Rich-Thin" user interfaces, which ultimately are neither "rich" nor "thin". They're not rich, because they're so difficult for developers to implement. They're not thin because user's wait while extensive JavaScript runtime engines are downloaded to the browser, the behavior of which may be different from one browser to the next. They're less stable. They're harder to maintain. These user interfaces seem to be byproducts of server lag times that occur in request-response cycles, due to poorly performing server technologies, such as J2EE, .Net, script based interpretive environments, and bulky documents that traverse limited bandwidths. It's much easier to implement and support server based UI control logic, but people need interfaces that are more responsive. This isn't to say that JavaScript is bad, but that minimizing it's use seems like a good goal, from my perspective. Asynchronous processing, as pointed out in this article, can be quite useful. My suggestion is just that it be used appropriately, and not become too closely associated with the "Rich-Thin" approaches to development that I've briefly alluded to. Nathan Andelin

[D.Kenzie]

** This thread discusses the article: Use AJAX for Bright and Shiny Web Apps **
Nathan, I agree with your comments about the problems with the DOM and Javascript being hampered by limited debuggers. In writing our web applications, both internal and external, we are much, much more productive with the server-side code development than the client (aka Javascript) side. The lack of a good Javascript debugger is especially frustrating. Some of the difficulties with Javascript can be mitigated somewhat by using a library of pre-built functions - either home-grown or freeware/commercial products. These at least can be written to hide problems with browser compatibility and inconsistent DOM support. With regards to AJAX, my upcoming follow-on article uses an external script to encapsulate the AJAX functionality, so it is easy to implement with a single reference to an external source file and a relatively small amount of code. I do agree, though, that like any technology, Javascript must be used judiciously. For example, I prefer to do all data validation server-side, because it's just too easy to turn off Javascript and therefore the validations. Duncan