I finally sat down and started work on a sandboxed DOM API. Originally I was just going to develop a new framework because the DOM is messy but instead I decided it would be cool to have a safe simulated DOM instead and build a framework on top of that.

It isn’t complete yet and there’s still a lot of work to do but it’s working pretty good. I still need to run some tests on it and try to break it but I don’t have time at the moment as I need to do other stuff.

One of the problems making a DOM API is that IE doesn’t have setter support even in IE8 it doesn’t allow you to define setters on normal objects. Because I spend most of my time hacking stuff it was a fun challenge to make IE support setters on DOM objects and keep my sandboxed whitelists.

It’s quite complicated and quite ugly in parts but it works and I think it’s the only way to support legacy browsers like IE7.

How it works

I have to test for the various setter support including defineSetter, Object.defineProperty and revert to the legacy onpropertychange. Object.defineProperty works fine in IE8 when using a DOM object but I encountered problems when I needed to assign to a sandboxed normal object. Here it gets ugly, I had to create a DOM object for any styles used by a node, this way both Object.defineProperty and onpropertychange allow me to monitor any assignments to the fake style object.

var styles = document.createElement('span');
node.$style$ = styles;
Object.defineProperty(node.$style$, '$'+cssProp+'$', {});
document.getElementById('styleObjs').appendChild(styles);
node.$style$ = styles;
node.$style$.onpropertychange = function(){}

As you can see with the code sample above I have to append the fake style DOM object for onpropertychange otherwise it won’t be called on assignments.

You can see this working by using the following test code:-

document.getElementById('x').style.color='#ccc';

So I proxy off all these functions and make the root node any html object, I use CSSReg and htmlReg to sandbox each modification to a property. Finally where it got complicated was supporting events, currently I only support “onclick” as I’m still testing but what happens is because the code is already sandboxed I don’t need to perform a rewrite so I pass this to JSReg as it’s already been converted, I supply the “this” object as the html element this allows the triggered event to call “this” as the current element.

That’s it! I’ve donated the code to OWASP and it will be free to use in your projects, any help testing or suggestions are most welcome, enjoy the demo!

Sandboxed DOM API

First, create a sequence collection that you can use to determine the next identifier in the sequence. The following creates a collection called seq that has a single sequence in it (for users), but you can add as many as you need:

db.seq.insert({"_id":"users", "seq":new NumberLong(1)});

Before adding a new user, you need to increment the sequence by one and fetch the next identifier. Fortunately, the findandmodify() command provides an atomic way to do this. Using the MongoDB shell, the command would look something like this:

db.seq.findAndModify({
    query: {"_id":"users"},
    update: {$inc: {"seq":1}},
    new: true
});

Because I'm using Lithium, I added a method for fetching the next identifier to my User model:

<?php
 
namespace app\models;
 
class User extends \lithium\data\Model {
 
    static public function seq() {
        $seq = static::_connection()->connection->command(
            array('findandmodify' => 'seq',
                  'query' => array('_id' => 'users'),
                  'update' => array('$inc' => array('seq' => 1)),
                  'new' => TRUE
            )
        );
 
        return $seq

Truncated by Planet PHP, read more at the original (another 2980 bytes)

In the back end, we have models that connect to CouchDB. These models implement the Iterator pattern to allow easy traversal of a record’s keys.

When I wrote the code to implement Iterator several months ago, I dutifully checked the PHP Manual and adapted the reference example that I found there:

<?php
class Record implements Iterator
{
    // (partial class, showing the iterator implementation only)

	public $_data = array();

	public function rewind()
	{
		reset($this->_data);
	}
 
	public function current()
	{
		return current($this->_data);
	}
 
	public function key()
	{
		return key($this->_data);
	}
 
	public function next()
	{
		return next($this->_data);
	}
 
	public function valid()
	{
		return (current($this->_data) !== false);
	}

}

Little did I realize that this implementation is very broken. I’ll explain why, below.

Over the past few years, I’ve implemented many iterators in this way, using PHP’s implicit array manipulation functions (reset(), current(), key(), next()). These functions are very convenient because PHP arrays are so powerful — arrays in PHP work like ordered hash tables in other languages.

PHP’s implicit management of an array’s iteration index (the value that is incremented by next() and referenced by key()) is indeed convenient, but the convenience can sometimes be offset by its very implicitness — the value is hidden from you, the PHP programmer.

In PHP, generic array iteration (without the implicit iterator) isn’t actually as simple as it sounds. Remember that arrays aren’t arrays in the traditional sense, but ordered hash tables. Consider this:

$data = array('zero','one','two','three');
for ($i=0; $i<count($data); $i++) {
    // yeah, don't calculate count() on every iteration
    echo "{$data[$i]}\n";
}

Output:

zero
one
two
three

This first example is easy to iterate — the array contains sequential, numeric, zero-based keys. It gets more complicated when using non-sequential, and non-numeric keys:

$data = array(
    'apple',
    'cow' => 'moo',
    'pig' => 'oink',
    'orange'
);
for ($i=0; $i<count($data); $i++) {
    echo "{$data[$i]}\n";
}

Output:

apple
orange
Notice: Undefined offset: 2 in - on line 10
Notice: Undefined offset: 3 in - on line 10

I could use foreach, but because a numeric loop illustrates the point more clearly, here’s how I might implement the above code so that it works:

$data = array(
    'apple',
    'cow' => 'moo',
    'pig' => 'oink',
    'orange'
);
$k = array_keys($data);
for ($i=0; $i<count($data); $i++) {
    echo "{$data[$k[$i]]}\n";
}

Output:

apple
moo
oink
orange

This brings us back to the Iterator implementation. Why isn’t the code above correct? Take a closer look at this:

public function valid()
{
    return (current($this->_data) !== false);
}

A value of false in the array is indistinguishable from a false value returned by current(). Using the above implementation with the following array would cause it to bail after orange (and subsequently might cause you to waste a day tracking down the cause):

array(
    'apple',
    'orange',
    false,
    'banana',
);

On Tuesday night, I updated the manual to use an improved Iterator implementation. It’s probably a bit slower (so you can use the internal-indexing implementation if you’re sure your arrays will never contain false), but my implementation is more robust.

<?php
/**
 * A mixed-key iterator implementation
 *
 * Note: these array_keys() calls are slow. The array keys could be cached
 * as long as the cache value is invalidated when $_data is changed.
 */
class It implements Iterator
{
	public $_data = array();
	protected $_index = 0;

	public function rewind()
	{
		$this->_index = 0;
	}
 
	public function current()
	{
		$k = array_keys($this

Truncated by Planet PHP, read more at the original (another 765 bytes)

I’ll be giving a session called “Building a Web Service API” from 10:30 – 11:45am in the PHP track. Here’s a summary of the session:

When is a web application more than just a web application? Hook up an API and you’ll see! I’ll walk you through the basics of what an API is and the concepts behind it as well as key pieces of technology you can use to create both the client and server. There’s a focus on PHP but other languages and tools will be touched on as well.

There’s still time to register for the event – tickets can be purchased for an early bird price (ending today) of $50 or $60 at the door. You can see the full list of sessions here.

I've had several people ask me how this is done, so I think a post is in order.

While it's entirely possible to brew beer at home without any fancy gadgets, there are several tools I use (such as my refractometer) that make the process easier, more controlled, or both. Brewing software is one of the few instruments that I'm not sure I'd want to brew without. I use a Mac, primarily, so Beer Alchemy (BA) is the obvious choice for recipe formulation, calculation, and logging.

BA has its own html export mechanism for recipes, and I used this for quite a long time, but I was never really satisfied with the results. The markup was hard to style, contained a lot of clutter (occasionally useful, but often redundant information such as style parameters), and simply didn't fit well with the rest of my site.

You can also export from BA in PDF (not suitable for web publishing), ProMash's binary recipe format (a pain to convert, although there do seem to be some tools to help with this), BeerXML (normally the most accessible, but in my opinion, a poorly-designed XML format), or in BA's native .bar ("Beer Alchemy Recipe") format, which is what I chose.

The bar format contains a property list, similar to those found throughout Apple systems. Property lists are either binary or XML (but the XML is very difficult to work with using traditional tools because of the way it employs element peering instead of a hierarchy to manage relationships). Luckily, I found a project called CFPropertyList that allows for easy plist handling in PHP. (I even contributed a minor change to this project, a while ago.)

Once you've run the .bar file's contents through CFPropertyList, layout is very simple. Here's most of the code I use to generate my recipes:

<?php
$beerPath = __DIR__ . '/../resources/beer/';

$recipes = apc_fetch('seancoates_recipes');
$fromCache = true;
if ($recipes === false) {
	$fromCache = false;
	foreach (new DirectoryIterator($beerPath) as $f) {
		if ($f->isDot()) {
			continue;
		}
		if (substr($f->getFilename(), -4) != '.bar') {
			continue;
		}
		$cfpl = new CFPropertyList($beerPath . '/' . $f->getFilename());
		$recipe = $cfpl->toArray();
		$title = $recipe['RecipeTitle'];
		$recipes[self::slugify($title)] = array(
			'title' => $title,
			'content' => $recipe,
		);
	}
	asort($recipes);
	if ($recipes) {
		apc_store('seancoates_recipes', $recipes, 3600); // 1h
	}
}

In addition to displaying the recipe's data, I also wanted to show the approximate (calculated) beer colour. Normally, beer recipes declare their colour in "SRM" (Standard Reference Method). There's no obvious, simple, and direct way to get from SRM (which is a number from 0 to 40—and higher, but above the mid 30s is basically "black") to an html colour.

I found a few tables online, but I wasn't terribly happy with any of them, and keeping a dictionary for lookups was big and ugly. I like the way Beer Alchemy previews its colours, and since it has html output, I emailed the author to see if he'd be willing to share his algorithm. Steve from Kent Place Software graciously sent me an excerpt from his Objective C code, and I translated it to PHP. This might be useful for someone, and since Steve also granted me permission to publish my version of the algorithm, here it is:

<?php
/**
 * Calculate html colour from SRM
 * Thanks to Steve from Kent Place Software (Beer Alchemy)
 *
 * @param float $srm the SRM value to turn into html
 * @return string html colour (without leading #)
 */
public function srm2html($srm)
{
	if ($srm <= 0.1) { // It's water
		$r = 197;
		$g = 232;
		$b = 248;
	} elseif ($srm <= 2) {
		$r = 250;
		$g = 250;
		$b = 60;
	} elseif ($srm <= 12) {
		$r = (250 - (6 * ($sr

Truncated by Planet PHP, read more at the original (another 3023 bytes)

• Loading content from Midgard CMS to Aloha Editor
• Annotating our content with Google-compatible Person RDFa elements
• Saving the content back to Midgard
• ...and finally analysing the content with FISE to find more semantic information

The hackathon participants included developers from Nemein, Gentics, Infigo, Salzburg Research and the German Research Center for Artificial Intelligence. Some screenshots:

Editing content with Aloha in Midgard

Annotating persons with the Aloha RDFa plugin

RDFa annotation created with the semantic editor

Additional semantic information suggested by FISE

All the relevant code can be found from GitHub (see also the FISE Midgard integration).

sb@vmware Money % hphp -t analyze --input-dir .
running hphp...
creating temporary directory /tmp/hphp_Zz7AXg ...
parsing inputs...
parsing inputs took 0'00" (20 ms) wall time
inferring types...
inferring types took 0'00" (10 ms) wall time
saving code errors, dependency graph and stats...
all files saved in /tmp/hphp_Zz7AXg ...
running hphp took 0'00" (208 ms) wall time

The script below takes a CodeErrors.js file (which is generated by hphp and in the example above is saved to /tmp/hphp_Zz7AXg) as its input and print an XML document in Checkstyle's format (the same XML format that is also used by PHP_CodeSniffer, for instance). This XML logfile can then be used with Hudson, for instance, in a continuous integration context.