I read an article recently describing this concept at CoderHump. Ben Garney used it to make it easier for game artists and designers to tweak game settings without training them on an API or building and maintaining a separate tweak input tool for them to use.

This concept takes advantage of a useful feature of Google Docs spreadsheets: they can be set up to publish in ATOM format, which is XML. You can lay out columns and rows so that they correspond to variables and values like a flat-file database. There are docs on the API.

Like any Google Doc, you can set up access control if you want. If you want multiple editors, think carefully about how you deal with unexpected values. It would be nice if there was cell-level protection.

Step-By-Step

Google Docs:

Create a spreadsheet. Put in a couple columns and rows worth of data, such as the days of the week in column one and their corresponding name in Spanish in column two. (This could be an awesome translation tool, no?).

The settings you need are in the Share Tab on the Right:

Using Sharing settings… , publish the spreadsheet so that it is publicly viewable:

Then open the pubish as a Web Page settings from the same settings tab:

Change the dropdown menu from Web page to ATOM…

… and copy the ATOM URL to use in ActionScript.

Flash: Load the XML using the URL for the ATOM feed as the URLRequest string.

I needed a way to get all display object coordinates from XML to support a liquid layout. The XML Data format is specified to mirror the names and hierarchy of the display. The class used to get the data needed to be able to return data from any level in the hierarchy, since the display objects were nested clips.

Other XML getters I have written either expect the path to the data as a literal argument or assume a unique node name at a constant location. In this case I couldn’t provide a literal path argument because the path would differ with each call. The location within the data source could be any number of nodes deep. The end node in each case would be a coordinate value (“X”, “Y”, “Z”, “H”, “L”, “D”) corresponding to a display object attribute, by definition non-unique.

Using the …rest parameter enabled the getter to accept a series of arguments of any length and iterate through them in order to create the path to the data.

public static function getCoordinate( ...clipLevels):Number

Although it isn’t typed, we have to assume that each clipLevels parameter will be an XML node name. A caller looks like this:

private static const scaledSizerX = ContentMeta.getCoordinate("HEADER", "SIZERRADIOGROUP","_SCALEDSIZER","X");

Each string must be in the order [highest to lowest] to build the correct path to the data. A local var [query] stores the result of the highest level query, which is the only one against the data [coordinates_meta].

var query:XMLList = coordinates_meta[clipLevels[0]];

After that, looping through the cliplevels arguments (args = clipLevels.length) against query gets down to the data:

for (var i:uint = 1; i < args; i++)
{

query = query[clipLevels[i]];

}

Then recast the result to a Number and return it to the caller:

returnVal = Number(query[0]);

return returnVal;