Core Features

We heavily use AJAX to allow immediate editing of all the page content. Pages do not require JavaScript to be read, but any work on a page requires full JavaScript functionality. The code sends POST and at times GET messages to the server to maintain the page as expected and keep the server synchronized.

For example, you are able to log in a page using AJAX so the page doesn't need to be fully refreshed. Similarly, editing the title of a page just requires a click on that title.

We have to think about several side effects of using AJAX:

~~All AJAX code should access the server under a specific folder named "ajax". For example, the log in feature would use ajax/login to post the user log in credentials.~~ This idea was for security reasons, but our permission scheme is way more advanced than Drupal's and thus this is not required.
In some situations, AJAX tends to send many requests one after another. For example, an auto-complete feature sends a new request each time the user enters a new character in the corresponding text field. This has side effects on the anti-hammering feature, for example. We have a JavaScript class to handle trickling of such messages where needed which we already used a a couple of places with great success.
The reply of AJAX requests cannot be cached because they are computed differently than when managing the cache of a complete page. Plus AJAX is always expected to be dynamic.
The server needs to know whether it was hit by an AJAX request or a standard request. AJAX should always be answered using XML files. This is done by adding the _ajax variable to the request. Note that won't help a hacker get in, but it can be used by authorized users to see the XML reply of the server (although with a debugger, you can generally see it attached to the POST message.)

Keyboard

When in edit mode (logged in) the user can click on items to edit them. In some cases, items are defined in an anchor (i.e. the logo of a website.) A click on the item holding the Ctrl key down enters the edit mode, otherwise the link is followed normally. [TBD]

If possible we want to show an Edit "frame" so the user is aware that the click is going to edit the data (i.e. when hovering the mouse and the Ctrl key is held down, this can work by adding a class to the body tag which is partially implemented--we ignore the Ctrl key scheme at this point.)

Save Button or No Save Button

Small edits, such as changing a small set of flags (i.e. is page allowed in the XML sitemap?) should not include a Save button. When you click on the flag, the new state is sent to the server directly. If you have a screen with just flags, all can behave the same way.

However, a large text editor is probably better with a save button because users know of that one. Although we should allow for an auto-save, but that can cause problems of slowness (i.e. while auto-saving a draft on a slow client, the user may not be able to continue smooth editing...)

Error handling

If the server fails handling a message (i.e. user doesn't have permission,) then an error is shown to the user at the time we receive the answer. The process sending the AJAX request must be pro-active in handling the error response, but that is like two lines of code: was there an error? yes, then call show messages.

If the server does not answer in time (i.e. timeout) then the timeout error is shown and probably a button allowing the user to try again.

If the user tries to leave a page before the AJAX process receives the answer to any message sent to the server, then a warning dialog is shown and the user has the choice to lose some or all of his changes or wait until the transaction replies were all received. Since this works by catching a message, the editor system handles this directly.

TODO

At this time the server_access plugin always sends a POST variable named _ajax set to the value 1. There seem to be a header sent by existing frameworks that tells servers that the request is an AJAX request. The header is: