The Atlas framework has two distinct elements - a client script framework, and a set of server extensions that integrate Atlas with ASP.NET. The client script framework is 100% Javascript, and works with any modern browser. But it is also completely server-agnostic, and works with any web server.

Of course, Atlas and ASP.NET together provide the best, most seamless end-to-end programming model that integrates the client and server. But if you're trying to use Atlas with a different server platform, you can go and write the server components that integrate in similar functionality.

So how do you go about using Atlas with another server? When you install the March CTP, you'll notice that the install creates a folder under the Program Files directory. Look in here, and you'll find the Atlas client scripts, in both debug and release versions. (The release versions have been compressed for size.) You can now just pick up these files and drop them into a ScriptLibrary subdirectory in your web project, and you're good to go!

Well, not quite. If you're just doing a client-side app, Atlas client script is all you need. But if you want to connect to the server, you'll want to write server-side code to talk to the Atlas client. Here are some examples of features built-into Atlas when you're using ASP.NET, but that you might want to write yourself when using another server:

• Accessing web services:The Atlas extensions for ASP.NET automatically generate Javascript client proxies for web services and components hosted in ASP.NET, and automatically handle serializing .NET objects to and from Javascript using the SOAP protocol. Atlas also includes a data service that manages synchronization of sets of data with the server. You'll need to do this yourself with a different server platform, although you can rely on an available JSON serializer to help you.
• Integration with server programming model:Atlas includes a set of server controls that allow you to use it from ASP.NET pages without learning Javascript. If you are using Atlas with a different server UI framework, you'll want to write your own integration.
• Browser detection: The ASP.NET ScriptManager control automatically detects what browser the user is using, and sends down the right part of the Atlas browser compatibility layer. With another server, you'll need to do this yourself, by checking the user agent string.
• Application Services: ASP.NET provides a set of rich application services, such as the ability to store and validate user credentials, and a profile service to store per-user data on the server. Without ASP.NET, you'll need to roll your own.

At the MIX conference a couple of weeks ago, I showed how you can use Atlas with PHP. To do this, I wrote some PHP code providing the server end of the Atlas web services stack, including a base class for implementing REST web services, a class for generating Javascript proxies from these services, and a serializer built on the excellent open-source PHP-JSON serializer.

You can download the PHP sample here. To install it, expand the contents into a folder, and then copy the Atlas client scripts into a ScriptLibrary subdirectory as mentioned above. Now, you can set up your PHP server to point to this directory. Browse to 3_3_DataBinding.php - the web page - and you'll see both Atlas autocomplete and client-side databinding in action.

The root directory contains the sample content, but the real fun is in the AtlasPhp subdirectory. This folder contains the PHP-JSON serializer (JSON.php), the web service base class (AtlasService.php), and the script proxy generator (AtlasProxyGenerator.php). It also includes a file called ApplicationRoot.php, which you’ll need to change if you install the app to any PHP URL path other than the default (/Examples).

To build a web service class, you can just create a new PHP file, include AtlasService.php, and write a class that inherits from AtlasService. Here’s a simple example:

<?php 

require_once("AtlasPhp/AtlasService.php");

class AutoComplete extends AtlasService
{
    function GetWords($prefixText, $count) 
    {
        $count = ($count > 0) ? min($count, 5) : 5;

	$results = array();
	for ($i = 0; $i < $count; $i++)
        {
            $char1 = chr(rand(97, 122));
            $char2 = chr(rand(97, 122));
            $char3 = chr(rand(97, 122));
            $results[] = $prefixText . $char1 . $char2 . $char3;
        }

        return $results;
    }
}

$service = new AutoComplete();
$service->ProcessRequest(null);

?> 

There are some interesting challenges in building the server proxy generation and serialization stack for PHP. The biggest of these comes from the fact that PHP is mostly a dynamic language. So, methods in PHP don’t really have fixed types. This means that, although we can (and do) serialize objects returned from PHP to Javascript, we can’t figure out the right class to create when serializing Javascript back to PHP objects. The prototype solves this in a simple way – it assumes PHP associative arrays for all parameters. If you’ve got a better approach, I’d love to hear from you.

So, how compatible is the PHP implementation with the ASP.NET one? Well, for the examples I included in the sample – which includes an autocomplete textbox as well as a request to get and databind to data – the only thing I had to change from the original ASP.NET-based example was the URLs. Other than the JSON serializer, the core code for the sample is only about 3.5K of PHP.

Now, I am admittedly not a PHP expert, and if you find flaws in my code, I’d be happy to get your feedback. But what I’d really be interested in is someone wanting to build a richer solution integrating Atlas with PHP – or with Perl, or ASP, or Rails, or some other web platform. If you’re game, drop me a line – I’d be happy to help you with pointers along the way. Happy coding!

Download Atlas_Php.zip.