I wrote recently on the topic of Isolation Testing in PHP as part of 1.2, and two methods are available right out of the gate. The more conventional of methods uses php's proc_open command. The web interface though takes advantage of the server to fan out processes to do work. Using the YUI Library, the newest version sports a web interface using the YUI Get Utility (with a callback) to ensure every PHP test runs independently. As an added bonus, on obscure windows installs where the multi-process model was pitching fits, WAMP (A and M not required) can now do full isolation testing.

In addition to the web interface and the command line version of multi-process support, the Mock Object engine got an overhaul with full static method support and private method inspection. Lastly, TAP support has been really improved. The output streams, tests are counted before running, and notImplemented() was changed to todo() for marking tests that haven't been done yet.

All in all, it's a great release, and is strongly encouraged for all users to download. The release can be picked up either through SnapTest Google Code or from SnapTest GitHub. Happy testing.

And no matter how many times I tried, IE (6 specifically) refused to check the checkbox. It turns out IE want your checkboxes made in a Mozilla-incompatible way. Specifically, IE lets you call document.createElement using an entire HTML tag, which will result in a node you can perform operations on.

I almost fell back on the conditional comment browser sniff from Dean Edwards, but ended up with something I felt was much better. Everything beaten into your head about JavaScript says that feature detection is the better alternative to browser sniffing, so why not treat IE's rendering of an HTML tag as a "feature" instead of a bug.

A couple minutes later, I had a working solution.

I guess I had never really thought of IE's bugs as features before; changing the way you can code for IE's differences from other browsers.

When doing research on how to spawn sub processes cross-platform, the options end up being very limited. Since forking is not available on window boxes, the only two available options seemed to be popen() with STDIN and system() with a socket connection. With inspiration from Ming's spinlock concept for JavaScript, it was possible to spawn the needed child processes, and check back on their output in a round robin fashion. Using /bin/nice (or the /low switch on windows) also keeps any one process from starving the parent.

The final piece was building out the classes needed. Specifically, a dispatcher for managing and collecting data off of STDIN and an aggregator for handling completed result sets. The bare bones structure ended up looking a lot like a simple JavaScript event model:

The final implementation ends up being a bit more verbose, but the concept is there. Unfortunately, one caveat of this approach is that calluserfunc_array() is not known for its speed, as PHP isn't very good at mapping an array to function arguments.

The code implementation is visible in the SnapTest repository and will likely end up in the next release. The next step though is to get the web-testing interface (and then the web-services layer). AJAX makes a much better multi-process controller, and while it can only handle 4 children at once for the same domain, it does create a truly asynchronous test with all the benefits of isolation.

The second of the housekeeping stuff actually manages to eclipse my excitement about the SXSW thing, I can actually cross something off my life-to-do list. (Not that speaking at a conference isn't on there, I just haven't spoken yet.) Instead, I'm talking about the release of an open source project which I've been working on for some time out in the open. SnapTest, a unit testing framework for PHP, version 1.0.0 alpha is finally out. By "out" I mean there are wiki pages, documentation, and even a shiny .tar.gz waiting. While most projects I tend to do are for fun, personal benefit, this one has a certain tangibility (usefulness) to others.

I've been a big fan of Test Driven Development since I first encountered it so many years ago, but PHP was never very good at it as far as languages go. It was a bit kludgy, testing was difficult, and until PHP 5 objects were a bit of a joke. The language has done a lot of growing up though, and with all the new OO support, PHP can support some more robust testing concepts. In many ways, Snap is also an experiment in using PHP's exception handling as a means of properly catching debug information when tests fail. While perhaps not the most elegant of solutions over magic constants like __LINE__ and __FILE__, it provides a consistent interface for tracing down class, method, line, and file information in one complete package.

The most amazing thing is the feeling of accomplishment for getting something done. I owe a lot of thanks to Karen and Ryan for their help in building out the classes and concepts (and naming it), and for everyone who gave pointers here and there as it was developing. To the last part, you know who you were, and I'd love it if you'd all officially join the project. While I've done a collection of smaller projects, one offs, and contributed to other things before, I've never really been the lead on an OSS project before, so this is bound to be a good learning experience.

Getting the JIT Loader

The most recent version (1.0.0) can be downloaded here:

Update: A small typo was fixed in the verifier check, but was not significant enough to throw people, so the version number hasn't been bumped. Thank you -P for catching that and sending it in.

• Get the most recent JIT Loader (23k)
• Get the most recent JIT Loader - min + packed (5.6k)

The locking utility is also included, but if Lock exists, it won't be used. Enough thanks can't go to Ryan Grove for the original Lazy Load utility. The JIT loader, like LazyLoad is released under the New BSD License.

Putting off Loading the CSS and JavaScript

The method of loading we are specifically looking at is known as "event based loading" or "lazy loading". While the wikipedia article on lazy loading is not very detailed, the summary of the article is that lazy loading allows us to wait on loading stuff until we need it. In computer science, usually the discussion revolves around expensive objects or data calls. In our case, it's all about the browser load time. There's little reason to put JavaScript or CSS into the head of a document unless we know it is 100% needed for the page. We want to put off the expensive http connection and download as long as possible.

A very practical example (and one already out there) is to defer the loading of images until they are within the viewport. Both the JQuery Lazy Load Plugin and the YUI Image Loader do exactly this, reducing load times on pages by holding out on pulling down images until you need them. For these examples, scrolling the page (and moving a placeholder into the viewport) is an event that triggers the load. If this has proven successful for images and content, there's no reason this can't be applied to scripts and CSS as well.

Loading JavaScript In Existing Frameworks

To a certain extent, Dojo and YUI have both built in a loading system for including packages before executing script. They are the dojo.require() directive and the YUI Loader Utility respectively. These two were specifically called out because their methods of including requested files are so different.

In the case of Dojo, an XMLHttpRequest (XHR) is made to load the JavaScript package, and then is ran through eval() to convert the request into functional code. This lets Dojo use a package style syntax similar to Java for including libraries to run. Each call to require() is synchronous and blocks, meaning you can trust a directive to fully complete before getting into your code. This method is highly effective for lazily loading a package since Dojo is clever enough to not include something twice. The crutch though is the XMLHttpRequest, which is subject to any cross site scripting issues. (Note: AOL has managed to do a custom Dojo build with XHR support across domains and the process is pretty well documented, but it is not the default behavior.)

On the other end of the spectrum, the folks at Yahoo! have taken a different approach, writing to the DOM directly using the <script> tag. This eliminates the cross browser issues that Dojo grapples with, but trades it for the limitations of inline script writing exposing the DOM to Internet Explorer in a state when it's not "complete" in IE's mind, resulting in the dreaded Operation Aborted error. In order to use the loader, there's also a lot that needs to be done if custom modules are going to be used. (As of this writing, the YUI Loader constructor does not take the config object, so it's hard to dynamically add to the object without using YAHOO.lang.augment().)

Ryan Grove built a library independent utility for including scripts, similar to YUI, called Lazy Load. It was a good strong start, and needed a steroid boost to provide the CSS support and streamlined DOM writing. Because the API and usage was radically changed, the name was changed to reflect its new usage.

Just In Time Loader (JIT Loader) Basics

In most situations, the behavior we are looking for is "on event X, load this, then load this, then load this, then execute Function X". To provide access to this streamlined interface, JIT.startChain() was created. Calling startChain() returns a method-chaining object that you can use to build up a series of Javascript and CSS includes. The following methods are available on the object returned from the startChain() call.

• addCss(urls, verifier, ie_version): adds a CSS File (or array of CSS files) to the execution stack. It will continue when verifier returns true. By default, all verifiers simply make sure the nodes have been written to the DOM, not that they have been processed internally. In the case of CSS, you can specify a specific IE version you want to apply this CSS to in order to keep your CSS files clean.
• load(urls, verifier): adds a JavaScript file to the execution stack
• loadOnce(urls, verifier): adds a JavaScript file to the execution stack. When fired, if the URL has already been added by another JIT load or an external source, it won't be loaded again.
• onComplete(function, obj, scope): Starts the execution chain. When the execution chain has completed, function will be ran. If obj is suppled, it will be passed as an argument. If scope is true, function will instead be directly ran in the context of obj.

The most primitive example of chaining would then look something like:

If chaining is not your thing, you can also make direct calls to the JIT object (see examples at the end). After the verifier, each of the above calls takes a callback function, object, and scope; the onComplete() doesn't exist in the root JIT object and is used solely for the purposes of chaining. These are left available in case more advanced functionality is required.

Optimizations

Because JavaScript is (mostly) single threaded, if there are multiple calls to the Lazy Loader, we shouldn't wait on the current code execution block to write to the DOM and clean up when it is finished. The original Lazy Load used a queue system that let multiple calls stack as pending, even if they were for different load requests. The smallest synchronous operation is the DOM write, which can be pushed out to a method and can be locked using a spinlock to emulate fake threads. Any events that get queued up between DOM writes can be added to the stack, and can then execute while slow scripts take a while. This speedup is surprisingly most noticeable on Internet Explorer, where events are allowed to interrupt the current JavaScript thread, to write more concurrent nodes into the DOM.

Limitations

The verifier function that is passed in is the linchpin of the event based loading. When the verifier resolves to true, the loading process continues with the assigned callback. When working with CSS, this is exceptionally difficult. There are two options when dealing with event loading the CSS files, either find a testable property in the CSS, or pass in null for the verifier slot, and load the CSS first. While the first offers more reliability, the second tends to be more practical, since the CSS won't usually apply to anything other than nodes created by the JavaScript. A simple example of a CSS verifier would be (assuming your CSS sets the body's background image to the below mentioned URL:

The second major limitation of the system is in loadOnce() which requires script nodes to exist in the DOM to test if they have been properly loaded. This testing method makes it incompatible with the dojo.require() directive which uses the XHR to perform script includes. In the future, the verifier check might be ran once to preemptively test for component loading, but that will cause issues with testing in the YAHOO namespace.

Enough Already, Examples Please!

If you've had enough reading, here's some examples of JIT being used:

• Multiple Calls, Slow Server: Multiple JIT calls, where the call chain is intentionally stalled. Makes it possible to see how IE can optimize the load calls.
• Proximity Loading: Using a precursor event to start loading as quickly as possible. Clicking on the button starts a load chain (which will always be one step behind) with a show command on the end. This demonstrates using a user's likely behavior to prepare incoming JS.
• Advanced Direct Usage: For direct access to the JIT object, more intricate behaviors can be built, for example, pausing the include to run JavaScript, then resuming the includes.

You can also see JIT in use on the website Gaia Online for the Cash Shop (under the market submenu) and eventually in place for the world map and other header-based events.

The problem is made worse with several setTimeout() calls. As a single thread, JavaScript maintains some sort of event stack, where all of the callbacks and timeouts pile up, waiting for their turn. Once the event stack is out of events, the timers start again to count down to execution. If you fire one call with a setTimeout() and a timeout value of 2 seconds, and one more second of code execution follows, there will still be 2 seconds on the timer since it has not had a chance to run.

In a perfectly timed environment (running just this code), foo will execute, followed by bar, followed by foo's call to bar. In reality, the ms calibration for this is iffy. The output comes out as foo=1, bar=2 then foo=1, bar=1. However, simply looking at the timing values, our alert calls should be reversed. We've entered the world of volatile variables and shared space without even knowing (and probably not even wanting). Under the hood, it appears that making a call to alert(), prompt(), confirm(), or any other window level call pauses the current thread's execution, letting any pending setTimeout() calls resolve. When the execution returns from the window event, variables that were scoped one block higher could have changed without the knowledge of the current execution block.

A more practical example of this can be found on the Threadsafe JS Example Page. As of this writing, IE and Opera execute things properly in order, waiting for the prompt() to finish before continuing the current code block, and after completion, letting the pending setTimeout() event fire. In Firefox and Safari, during the prompt() call, the setTimeout() executes, overwriting the value of bar.

Protecting A Volatile Bar

As mentioned before, when the browser's JS Interpreter hands off to the alert(), it begins resolving any waiting setTimeout() calls that in in the event queue. In our example, another call to bar() is waiting which also increments bar_count. By the time we alert bar_count, something has gone and changed it. This seems to also hold true for prompt() and confirm() in Firefox and a few other browsers.

Imagine instead of just our primitive window.setTimeout() we were using an AJAX callback which waited for a DOM node to be available. The costs of this shared variable space being violated is a bit more costly. In many other languages, there are Mutexes the synchronized call, and the volatile declarative. Because the implementation of ECMA is unique to each browser, there needs to be a consistent way to secure data from tampering during the application's critical moments.

At our disposal is the following JavaScript knowledge:

• new Object() is atomic (can't be interrupted by browser events)
• return (new Object() === new Object()); is always false as each new object is given a unique ID by the system. We need a way to atomically create an ID for a fake thread.
• Array.push() is atomic (can't be interrupted by browser events) as long as we are using the native implementation. This non blocking implementation means even if two events get in the way of each other, only one will hold index[0] in the final array
• (function() { new Object(); })(); is garbage collected properly
• block scope level variables cannot be changed by outside factors

That doesn't leave us with much. Ming made a post on JS Mutexes that got the ideas flowing. The biggest concern from Ming's entries was that in Internet Explorer, events such as onload can interrupt a process, creating multiple events at the same time. To get around this, we would need a method which the browser cannot interrupt. This is where the native Array.push() comes in handy. For some reason, IE treats this call as non-interruptable, letting us have a queue process that ensures element 0 is the first lock requester. If we have two atomic commands, one to uniquely identify a lock request and another to enqueue the lock, then we have everything we need for a very basic spinlock implementation. Even if a second event interrupts our two statements, the pushing onto the array guarantees only one of the two requests will be given rights to the lock.

Spinlock design implies a "busy wait" cycle for getting the lock, meaning each individual thread usually sits in the equivalent of while(1) {}. Because we don't have threads and instead have the event queue, a while loop would seize the system. To get around this, we can use the same setTimeout() call that was the source of our problem to "sleep" an event until the lock resource is available. The result is a very lazy locking method that requires the application to care about the lock (but a lock that can be used in many different ways). Our pseudo code looks like:

Return to the Threadsafe Test and try the protected version. Across all browsers, the lock is held until the process has properly completed.

Beyond Locking Down Variables

A locking system like this can be extended to deal with more than just the Javascript Variables. In the case of lazy loading javascript, it is possible to be using the same utility to load several "sets" of Javascript at the same time. To avoid keeping the document.head open (and risking Operation Aborted problems), we use the same locking strategy to keep a DOM node from getting written to until Internet Explorer reports it as closed, such as an onreadystate for a script tags.

The locking utility can also be used to create "run once" functions such as an init() for a class outside of its constructor. The class can simply request the lock, and on completion, refuse to release it. While this takes up a small bit of memory in the lock utility, it also guarantees only one init() reaches the critical section for the life of the page.

Limitations

Building such a locking system in JavaScript is not without drawbacks. The most notable of these is the lack of support for browsers which do not support Array.push(). If this browser needs to be supported, there's not much that can be done via this method, or you can simply take your chances and code with very clear and isolated callbacks and timeouts.

It's also unknown just how atomic the methods are. While in brief tests in Rhino this appears to be atomic during the critical push step, there's no guarantee that it is actually going to be atomic if the browser makers create true Multi-Threaded JavaScript. Hopefully by then, there will also be the volatile keyword.

Step 1: Getting MacPorts, Installing Base Software

Update Aug 08: It was pointed out that you need the OSX Developer Tools installed. They are on the OSX CD, and enable the ability to compile things. It's a must have for this to work.

We're skipping the Fink v MacPorts (formerly Darwinports) discussion completely. The simple answer for this is that MacPorts has the builds we need at the versions we want. You're more than welcome to tackle this with Fink, as the concept will be identical. The absolute first thing you need to do is grab the MacPorts installer and get it up and running. Open the .dmg file, install, open a Terminal window, and run:

This will bring MacPorts up to date, and ready to do the installs. To get git-svn up and running, we'll need ultimately Git (1.5.2.3), Subversion (1.4.4), and the dependancies for the SVN/Perl Bindings. With the ports collection installed, we'll install the Git Core, Subversion, and SWIG (a dependancy for the perl bindings).

Yikes, that's a lot of dependancies! That's okay though, the ports collection will handle adding everything you need. As an added bonus, it will all be in /opt/local, meaning your normal OSX software remains untouched. Once up and running, you'll notice that the version of Git provided by MacPorts is slightly out of date. We can fix that, but at least all the dependancies are now in place. From here, we can build our missing gaps from source files.

Step 2: Build from Source

We'll need to download the latest Git and proper Subversion. Go grab those tar.gz files, and take care to match up your Subversion download to the version installed by MacPorts. You can find that by entering at the Terminal:

You'll need at least Subversion 1.4.4 for this to work, although I'm sure newer revisions would work as well. With both downloaded, we'll install first Git, and then the Subversion Perl bindings. Open a Terminal window, cd to the location of your Git download, untar it, and run the following commands

By setting the prefix to /opt/local, we'll overwrite the current Git install with our new version, including the new git-svn scripts we'll be wanting. Attempting to run it though informs us that the svn-swig libraries are not in place yet. We'll need to make those.

We won't be installing all of Subversion. Instead, we will be going all the way up to the install step and stopping. This way, we have the svn binary, working swig and neon paths (we won't care that autoconf says our neon is "too new"), and the original OSX version of Perl which has the really wacky library paths. Thankfully, OSX also is smart enough to put our libraries in the right spots. Change directory to the Subversion download, untar, and run the following

Like Git, we'll put it in /opt/local. That will fill out any of the problems we were having with the Perl libraries being in the wrong place (or not existing at all). You could try to install Perl 5.8 from ports as well (in fact, trying to install subversion-perlbindings forces it), but every time I had two sets of Perl on OSX, things got a bit strange. Once complete, you can test your install with

Beyond "Fun"

The concept of fun is so confusing, that the more a person tries to define it, the more confusing the concept becomes. Instead, fun is better described as a summation of things; interestingly, these things in and of themselves are not necessarily fun, but instead are foundations of an online emulation of life. In 1943, Maslow created a Hierarchy of Needs, which described the basic needs of human beings. Later, Nevis revised this theory slightly, adapting it based on his studies of East Asian values.

We can assume that because visitors to community websites have access to the Internet, they also have their physiological and safety needs met. This leaves "belonging" as the common denominator of needs between both Maslow and Nevis' studies. It can be concluded then that "fun", is the combination of a sense of belonging, a venue for satisfying esteem, and ultimately achieving a state of self-actualization. When all three needs are met, as the sites we will be discussing show, users have a higher retention rate, contribute to the larger community as a whole, and become evangelists of the site in question. They become passionate users.

The Sites Being Talked About

Gaia Online: Gaia Online labels itself as the premier social hangout for teenagers, with the largest forums on the Internet, several games, and a customizable avatar system. (Disclaimer As of this writing, I am employed by Gaia Interactive, creators of Gaia Online.)

Newsvine: "Get Smarter Here" is the tagline for the online news site that is rapidly growing in popularity. Its primary features include commenting and voting on news stories, as well as a "Doppleganger" technology which can harvest information off of the popular newswire services. Members can run their own columns or get together and form groups to produce their own online focused mini news sites.

The Most Common Need: Belonging

As mentioned above, the most common need expressed across both hierarchies is the need to belong. Belonging in the most literal sense means to feel a part of a group. A very basic belonging can be achieved in simple groupings of interests, likes, and dislikes. Newsvine, for example, makes it easy for readers browsing by a category of interest to immediately locate people who are talking and writing about related topics. Thanks to Newsvine's weighting technology, there's a high chance the articles found will be interesting and the users will return once, then twice, then thrice. Eventually, the users will keep returning since the articles the users finds are of value to them. They have achieved belonging and are ready to contribute to the collective group.

Gaia Online doesn't have the direct categories of Newsvine, and therefore depends on the more conventional social networking means. Through forums, profiles, and journals, users communicate with each other while sharing a common goal- the quest for virtual items to improve their online avatar. While this isn't always a driving force behind users' site activity, it's a commonality all users on the site share, so users start interacting primarily for the gold. They play games, post, vote in arenas, and ultimately find their first friends on the site. When this happens, users find their "home", a thread or two they always return to where most of their friends are chatting. That first connection and those first friends create a strong sense of belonging, as those friends will often pull the new users into their favorite threads and hangouts, immersing them in a smaller subset of the Gaia community.

Some popular social networking sites achieve belonging by creating locations central to a users' network of friends. This sense of belonging users get is no less valid than those previously mentioned. However, the sense of belonging becomes very dependent on the users' primary network to remain on the site/service. A very solid case that illustrates this belonging pattern is Facebook and its "seasonal disorder". Before Facebook started broadening its audience outside of the college community, a wave pattern could be identified in the site's average traffic, with dead times in the summer and surges in the fall. This corresponded with the typical academic calendar. Additionally, as students moved through their final year of college, their "belonging" on Facebook faded. The use of Facebook as a tool for class information, parties, and networking became less valuable as the users' friends also stopped using the service. This resulted in a constant amount of attrition which ate away at any longevity the site hoped to achieve.

After You Belong

Continuing with the pyramid of needs outlined above, when users of a site have achieved a sense of belonging, the next tiers of esteem and self-actualization become available. In Western cultures, esteem is a highly valuable component of a community's success. People who feel they have accomplished something socially return to the places that make them feel better. Still, esteem isn't just about popularity, although being popular in the context of the community is certainly a draw. A site that promotes a sense of self-rewarding can also further a users' esteem. Much like how people who play MMORPGs feel proud of their characters, people who participate in communities feel good about their contributions. Following this logic, sites that make users feel good about their contributions will have users who contribute more. One popular method to measure a users' contributions is with a karma system. Newsvine has taken it a step further with its [Vinacity][vineacity] system, which takes the traditional +/- karma system, and rewards users based on their participation on the site. As users post, comment, and participate, pieces of their vine fill up, providing an outward status icon to the community of their accomplishments.

Gaia, like many other community/game hybrid sites, reflects esteem through the collection of the game's items or status symbols. Much how the vine plaque of Newsvine indicates someone's contributions to the community, a large amount of virtual wealth and item-based accomplishments can also provide a point for esteem. One of the most common activities on Gaia is the process of "questing," which has little to do with the MMORPG concept, but instead is a way for users to share their progress toward an expensive item on the site. During the quest, the users provide updates, take donations, and ask the community for help and support. Other members help out, and eventually the users' goal is reached. That item they acquired then becomes a symbol of status they wear proudly. As users participate in the site and accrue items and virtual wealth, they also achieve a sense of accomplishment. In both Gaia and Newsvine's cases, users feels like they belong, and feel good about their activity. At this point, it's safe to say they are regular users. All they need is something that makes them want to evangelize the site.

From Regular to Evangelist

Adding more ways to build esteem and provide opportunities for users to belong is not enough to promote a regular user to an evangelical one. Instead, users who are passionate about a site had an event which has pushed them from the point of being regular users to the point of telling others actively. There are several contributing factors which can collectively drive users to this point (in no specific order):

• Enjoyment of the site's experience
• Enjoyment of the people on the site
• Kicking-Ass at something
• Explaining the to others and what makes it fun

Beyond this, coming together in real life can accelerate this process greatly. Taking the online community "offline" puts faces and real names to friends who were once only pixels, and the site becomes a common ground. The Newsvine Relay For Life was the first community-wide event, that brought individuals together in real life while supporting the American Cancer Society. Those who participated still remain some of the site's most active users. The events that bring forth a "Random Act of Vineyness" (the highest honor at Newsvine) come with dozens of users who have taken an online experience and turned it into something personal and important to them. In short, it made a difference in their lives.

At Gaia, we see how we change people's lives all the time through the letters that we get and at the conventions that we attend. We've seen people who used our community to break drug addiction, find friends, and become better people. We've also seen the people who help community members selflessly in our Life Issues forum, and donate to the previously-mentioned quests. At the convention, these people get to meet for the first time. In the years I've been with the company, it's happened hundreds of times; people meet at the Gaia booth, shriek, hug, and then spend the next thirty minutes to an hour talking about the website. At conventions the users' real lives are brought back to their virtual ones with the ability to play real life games to gain virtual items for their avatars. The Gaia Panel experience is also amazing. A small section of the community comes together for two hours to talk about features, voice complaints, and ask questions. In this offline space, users feels responsible for the development of the website, and as stakeholders, take a deep interest in it.

So is it Kool-Aid?

Like Maslow's pyramid, a community site's success should be built from the foundation up. Deep moments of connection cannot occur until the prerequisite experiences of belonging and esteem are fulfilled. The end goal is to make something important to people and to make their experience "fun." When the social networking cloud settles, it's on these sites that the users will continue to invest their time.

References

Harlow, The Nature of Love

However, the value attribute of the button wasn't getting passed in. For the legacy code around Gaia, we have forms with more than one possible "submit" for an action. The most common case of this is preview and submit buttons we traditionally use in the forums. This left us with two scenarios:

Submit Buttons that couldn't be styled in Camino / Safari

or Button tags that wouldn't pass in their value to the PHP script (and shouldn't technically perform a submit either)

The final solution ended up being something right down the middle and using JavaScript to make up for Safari / Camino's shortcomings. Starting with a default submit button, we can replace it with a input type="button" node, and add a bit of JavaScript to the onclick to make up for the stylized button's shortcomings. The first block of JavaScript goes into the HEAD, and the second block can either go into an onLoad handler or at the end of the form tag, depending on how soon you need the replacement.

Replace FORMID and SUBMITBUTTONID with the relevant values. If you want to see it in action, check out a working example. The example will also echo out the form contents on submit. You'll have to forgive the poor PNG buttons.

Drawbacks

The largest drawback hands down is the addition of JavaScript. It's not something to depend on, and many steps were taken to ensure that the enhancement is progressive in nature.

Styled images will have to be styled to reflect the change from an input to a button node, and can be referenced via button#idNameofElement to apply all the necessary stylization.

• Part 1: Touching the Surface - Theory
• Part 2: Architecture and Components

Note: This article was written under the guise of PHP 4, which lacks a lot of object related functionality that would be beneficial to the development of the code used in these examples.

It's been a while since I've touched on the topic, mostly because I've been busy with work for Gaia. However, this incubation period has let the transaction system mature, and it continues to hold out well with over 29 million completed transactions in the last 7 months. Since its inception, it's been adjusted to support item granting, and is currently being extended to support transactions in the Gaia Marketplace / Auction House. In the first article, I covered the surface of the transaction manager, and some of Fowler's theories which were behind it. In order to avoid recoding large parts of the site, a lock-first mentality was chosen for how to handle keeping an account up to date. This time, we're going to focus on all the players / classes of the transaction manager and how they work together.

As in most programming languages, PHP provides support for both public and private methods within a class. In development, one of the primary objectives was to minimize the external facing interface for the end-developer, while still keeping the backend components easy for a developer to maintain. Each component was given specific tasks, responsibilities, and a list of classes that it would couple with in order to provide functionality.

For a helpful guide, I strongly reccomend having the following image open in a new window: Transaction Overview Diagram

Bank Transaction Manager

The first component is the first of three end-developer facing classes. The Bank Transaction Manager is responsible for creating Transaction Entries, adding Transaction Entries to its internal stack, and then processing the entry stack while reporting on the success or failure of the process. When a Bank Transaction Manager is initialized, it creates an Account Manager object for tracking the accounts which it needs to load. As entries are created with the createEntry() method, they are fed to the end developer and then added back in to the system via addEntry().

A Transaction Entry is nothing more than a shell object, providing a clean interface for setting an object's ID, it's attribute, quantity, and other associated properties. When addentry() is called, the Bank Transaction Manager uses these properties in order to decide what Account to load (via the Account Manager). This pairing is then set aside until execution.

During the execution phase, the Bank Transaction Manager tells the Account Manager to initialize all relevant accounts. It then loops through every entry/account pair and passes the entry into the account. In processing terms, these are called posting rules. Every posting rule has a boolean success, and the sum of all functions returning an ultimate success or failure for execute().

If any errors are encountered, the Bank Transaction Error (a simple static class) is written to with information about the failure.

Account Manager

In a horizontally scaled environment, a user's inventory or a row of trading information might reside on completely separate machines. To encapsulate the loading and saving of these various things is the reason for the Account Manager object. Requested accounts are queued up, and then loaded via a single call to loadAccounts(). Beyond simply loading accounts, the account manager should be able to

• handle information if the account has changed
• Prevent data overlap by avoiding querying for duplicate data
• provide an interface for the instantiation of new Account objects

During the execution of the Bank Transaction Manager, the Account Manager is called (specifically when BankTransactionManager::addEntry() is used). Accounts are queued for loading as entries are added, and are then loaded at once. There are two ways to load the account data, one which uses blocking, and one which does not. Even at 4.5 million registered members, the blocking method has not been an issue, and so that is the method we'll be talking about. In an InnoDB database, a row can be locked during the select phase as part of a transaction by using the following syntax:

The FOR UPDATE places a lock on the row, leaving your PHP script as the only script that has access until the lock expires. This feature is only available on InnoDB however, as the MyISAM engine supports neither row locking nor transactions.

When asked to save, the AccountManager calls the isChanged() method on every account in order to verify if it has been altered. Accounts which have been altered are then saved back to the database and the locks released.

Transaction Entry

There's not much to say about the TransactionEntry object. As a shell, all it contains is a data payload. It's information consists of: "how many", "of what", "with what serial", and "adding or subtracting". To help simplify the development end, the Entry object is extended to support Game items, Regular Items, Gold, and Gift Credits. During execution, these small instruction sets are passed to the Account object.

Account

Defined as the authoritative source regarding all data coming in and going out, these objects are modeled in spirit after the VO J2EE pattern. They exist to hold an account's data, and are decorated with methods to support the changing of that data. When the Account Manager calls loadAccounts(), every queued account object is asked for its database information and required fields. The sum of this data is aggregated, and passed into the importData($fieldName, $data) function. When the Bank Transaction Manager executes, it then takes every Transaction Entry object, and passes it directly into postEntry($t). It is at this point that the heavy lifting is actually done.

Every account maintains a ruleset for how its data is to be altered, known as "posting rules". These rules are very strict, and breaking them should cause the entire transaction to fail for the user and return an error. The most common example of failure is if the posting rule contains an item type that the account does not support, such as posting gold information to an inventory account. With a single public interface, the logic of altering the account information is also internalized, protecting it from the outside world. Upon altering the account, postEntry() will return either TRUE or FALSE, which will be evaluated by the Bank Transaction Manager object.

Adding new accounts or extending existing accounts to add functionality is very easy. The methods exposed publicly are small, specifically getDaoName() and getDaoFields() for Gaia's database support, importData() for loading, exportAccount() for saving, isChanged() for the Account Manager's save required check, and postEntry() for altering the account's data.

Code in Practice (End Developer Side)

For as complicated as this all seems, the code which ends up facing the developer is only the Bank Transaction Manager and Transaction Entry's public methods. The Account Manager and Account exist outside of the end-developer's scope, unless they are building in support for additional account types.