Integrating AJAX into a Framework

Whether you're planning to add only a few simple AJAX features or use AJAX throughout your site, integrating it into your current Web site design is a must. The more formal the framework, the harder the process isespecially if your framework provides a front controller that is heavily optimized for generating HTML. Frameworks without a front controller have an easier time incorporating AJAX because they can add a new entry point just for AJAX; many AJAX Remote Procedure Call (RPC) implementations provide code to help do this.

The way you integrate with a front controller depends heavily on the style of AJAX you're performing. If you're taking a document-centric approach, integration is generally easy; you just need the ability to create pages in the needed output format. (The controller's normal name spacing will work just fine.) This may take some new development, depending on your current design, because you'll need to generate small chunks of HTML (or other data formats, such as XML) instead of full pages. You will also need to make some naming decisions, such as whether you are going to put your AJAX pages next to normal pages or into their own distinct namespace. A distinct namespace makes it easy to locate your AJAX code, but it divides the code by usage instead of by function, so you can't see the AJAX code's relation to its non-AJAX version. Adding in AJAX pages next to your normal code lets you see the relation, but it makes it much harder to identify all of an application's AJAX-entry points. Either option can work well; the most important point is to use a consistent approach.

RPC AJAX implementations have the hardest time integrating with a front controller. This difficulty occurs because most RPC implementations are focused on exporting classes to JavaScript and have their own mini-controller implementation, which maps incoming calls to these classes. Many also generate JavaScript, which should be added to the page using a JavaScript include, which again needs its own basic controller logic. There are three main tasks you want to accomplish when performing this integration: managing what functions are exported to JavaScript, managing the permissions on those functions, and creating a clean entry point that fits the style of the current application.

The last task is generally the easiest to achieve. With most RPC libraries, you'll be passing information specifying which class and which function to call to the server. This information is similar to the section and page information that most controllers already manage; it allows for a pass-through or mapping system to be created easily. The problem comes with the first two tasks: If you enforce permissions at the controller level of your application, you may find yourself with no other choice but to create tons of stub functions to create the namespace needed for permission enforcement. The final task is deciding which functions to export. The simplest solution is to create classes that are used specifically for AJAX integration, but you may find that mapping functions on your current controllers is a better solution for you. If you need to perform complex permission or partial controller mapping, make sure to choose your library with that in mind. Some enforce strict name mapping between the server and JavaScript side, and most approaches like this will need a virtual mapping of the methods instead.

If you start using large amounts of AJAX in your application, you'll also want to look at ways to standardize your management of JavaScript code. Your framework will need a way to map the JavaScript that is needed to power each HTML page. In a small application, it can all be stored in a single file, but in most frameworks, you'll have various chunks of reusable JavaScript to manage. One way to manage this is to output all the needed JavaScript for a page through a dynamic page on the server, sending headers to allow the client to cache the JavaScript as if it were static. Another option is to build packages of prebuilt JavaScript files and then include the set you need for the page in question. Large amounts of JavaScript development will affect your framework in other ways as well, because JavaScript can become just as important as your server-side language.