Ajax CMS
Ajax offers the possibility for a better user experience for content authors as well as site visitors for the Web CMS world. It updates without full page refresh.
• Continuous Feel: Traditional web applications force you to submit a form, wait a few seconds, watch the page redraw, and then add some more info. Forgot to enter the area code in a phone number? Start all over again. Sometimes, you feel like you’re in the middle of a traffic jam: go 20 meters, stop a minute, go 20 meters, stop a minute … Ajax offers a smooth ride all the way. There’s no page reloads here - you’re just doing stuff and the browser is responding.
• Real-Time Updates: As part of the continuous feel, Ajax applications can update the page in real-time. Currently, news services on the web redraw the entire page at intervals, e.g. once every 15 minutes. In contrast, it’s feasible for a browser running an Ajax application to poll the server every few seconds, so it’s capable of updating any information directly on the parts of the page that need changing. The rest of the page is unaffected.
• Limited Capabilities: Some Ajax applications are certainly doing things people never dreamed were possible on the web, but there are still substantial restrictions of the web platform. For example: multimedia capabilities, local data storage, real-time graphics, interaction with hardware such as printers and webcams. Support for some of these is improving in recent browsers, some can be achieved by delegating to Flash, but many are simply not possible, and if required, would rule out Ajax.
• Performance Concerns: Constant interaction between browser and server can make an application feel unresponsive.
There are, however, quite a few well-known patterns for performance optimization such as browser-side caching. These usually suffice, even for fast-paced applications like stock trading, but Ajax still might not work for really time-critical applications such as machine control.
• Life cycle of an Ajax application
• Visit: The user visits a site the usual way, i.e. by clicking on a link or typing a URL.
• Initialization The page initially loads. Callbacks are established to handle user input, a loop might be established to continuously refresh page elements.
Event Loop:
Browser Event An event occurs, such as a key press. Server Request The browser sends a request to the server. …Server Response A moment later, the server responds, and the response is passed into a request callback function, one that was specified when the request was issued. Browser Update The request callback function updates the DOM, including any JavaScript variables, according to the response.
Of course, there are plenty of variants. In particular, many events are handled locally and don’t actually trigger a trip to the server. Also, some Ajax applications are short-lived and the browser interaction is eventually terminated with the user submitting a form. Others remain to interact with the user as long as they are in the user’s browser.
Note that the Browser Event and the Server Request occur in one thread, and the Server Response and Browser Update occur in a separate thread. This is due to the asynchronous nature of the server request. It’s actually possible to configure XMLHttpRequest to make synchronous calls, but poor practice as it holds up the user.
IT Articles 2007
جواب بصورت نقل قول