Category: "RIA"

AJAX Interaction Notes - dojo

Notes on using a dojo/RIA web interface to launch background (server-side) scripts.

  • File uploads can run under FF and IE with dojo.io.iframe.send, and it is a nice interface. There is another post on this blog, with sample code.
  • Synchronizing background server tasks with client launch and monitor requires the client to be able to identify script failure to execute, execute reporting whether the operation was successful or not.
  • Two-phase, asynchronous execution can be made much more secure by storing the second-phase action on the server. Thus, if the first-phase executes correctly, no information is required from the client to continue the operation. All data submitted can be disregarded.
  • Success or Error can be indicated with HTTP headers in cases where no data is required on the response.
  • Client-side redirects can be used to transition to the next phase after a successful run of one phase.
  • User should be alerted that scripts initiated through the web interface cannot be stopped (unless a mechanism is provided).
  • User should be able to return to a previously initiated scripts and view the output.
  • Background script output should be delivered to the initiator through an email. User should be able to suppress email.
  • Background scripts should deliver output in text only.
  • Server must be responsible for state management. Server must ensure background scripts do not collide with each other, or the data, and must provide an interface that allows the client to determine if administration should be readonly or prohibited when specific scripts are executing.
  • Server must be responsible for scheduling resource intensive tasks to prevent service interruptions.
  • An object is an excellent way to allow a single dialog box to submit data to different scripts without writing additional code. The object is then assigned to the AJAX content property.
  • Server must have intelligence to adjust state of client, for example hiding informational messages after termination, enabling buttons to allow continuation, and providing alerts for errors.
  • Initial error reporting can be limited to ‘Error’, a simple indication that something went wrong. After testing, common errors should be delivered with additional explanatory text.
  • Balance distribution of client side code. Although it is nice to split a page into many components that can stand alone, this increases the number of HTTP requests which has performance impacts. Building the javascript into a single file is one solution, bundling related code together is another. Templates should include only the elements that require template processing. Large sections of javascript should be removed. Use caching to improve performance.
  • Break server side code into components such that only the code required to execute is read. This doesn’t always work out perfectly, and there are impacts to opening alot of files as well, but the server impacts are less serious than the client side, because there is no data transfer.
  • Put some timing code into the application so you can see where the time goes. Use YSlow to improve page delivery performance.
  • Use FireBug to monitor traffic between client and server.
  • Use a log file to write out debugging information. Check the error_log frequently. Use echo, var_dump, and exit. Build graceful error reporting into the application from the beginning. This will make debugging much easier. Log all errors. Put a switch in to allow debug displays to be suppressed for production systems.
  • Use a tee (*nix command) to pipe script output to a file and into mail.
  • Document the entire process and describe it to the appropriate people. This will ensure you understand what is happening and that it is what is supposed to be done. Be ready to change.
  • Write a good test plan and use it.
  • Be mindful of security. Validate all inputs. Escape all command line parameters that are user submitted. Check for access privileges for all requests, at all times. Avoid divulging application details or data.
  • Copy script output to a temporary access area, do not grant access further into the server for output display. Identify script output with the script name and session id.
  • Have Apache execute as apache:apache, or nobody:nobody, and allow only those scripts that should be executed through the web to have execute permissions for that user.
  • Be persistent and creative.

AJAX Limits

AJAX and RIA’s are rapidly redefining web interfaces, but they can be expensive and complex to implement.

A key consideration is to keep server side logic on the server. Background scripts should be written to require little to no user interaction, and should allow users to view their progress as they execute, and receive an email of the results when they complete.

The synchronization required to preserve states across accesses and sessions is probably not cost effective. Accepting that the web can initiate resource intensive background scripts, but not interact with them (other than possibly killing them) is a reasonable consideration.

Testing for a script in progress should be done to avoid redundant and potentially corruptive requests.

dojo AJAX file upload demonstration

This is a demonstration or example of how one can use dojo.io.iframe.send to submit form data to a server. This is useful if you have file inputs, which cannot use other methods.

The page includes good notes, and all source can be viewed.

Polished UI - Cost Effectively

Tactics to produce a polished (web) user interface, in a cost-effective manner.

This is different than the design, in that these issues are related to the user’s interaction, rather than the visual presentation. For example, the visual presentation would include the page layout, images, graphics, choice of color, attractive menus and page navigation. User interface is more commonly a part of applications, and is intended to help the user accomplish what they must do with the application. The user interface must be fairly easy to understand, and should be polished to present a professional appearance.

  • Start with a toolkit and if possible, a theme that works with it.
  • Find an icon set. The link above is excellent. You may need more than one set, and, since you only need to purchase it once, it is worth choosing carefully. Be aware of any license restrictions.
  • Be creative. If you can’t find the ‘perfect’ icon, use a keyboard character, or a different icon.
  • Keep it simple.
  • Disable controls the user can’t use, based on the current state of the page.
  • Remember the functionality probably takes precedence over the UI. When pressed for time, get it working, then make it pretty.
  • Limit the list of supported browsers. IE6+ and FF2+ is a good starting point.
  • Keep track of the time spent per page. This will allow you to give better estimates, and help management understand the costs of the project.
  • Donate to support any free tools you use.

dojo Form Demo

This is a very simple demonstration of a dojo form. Please use ‘View Source’ to view the code.

Supporting server-side PHP.

json.php

Returns the submitted input. Demonstrates a ’successful’ transaction.

<?php
header('Content-type: application/json');
echo <<<END
{"sText":"{$_REQUEST['sText']}"}
END;
?>

error.php

Returns a 503, service not available.

<?php
header("HTTP/1.0 503 Service Not Available");echo 'Server side error';
exit();
?>

timeout.php

Sleeps for 3 seconds to force a timeout.

<?php
sleep(3);
?>

1 2 4 5