The Lazy Function Definition pattern was discovered and named by Peter Michaux.

Motivation

Generally there are two main reasons for wanting to defer defining functions until a later time (although with any pattern, many other applications exist):

1. Resources required for a function to be fully defined are not available until the page fully loads or until a user-driven event (for example, determining page scroll).
2. The resources created by defining the function are particularly taxing and may not even be needed (for example attaching event handlers).

Implementation

The Lazy Function Definition solves these problems by defining resources upon the first invocation of the function and then redefining itself so that they are not recreated during subsequent calls. All resources are stored via closure so they remain available to the inner function (which becomes the new definition for the outer function).

var getResource = function () {
    var resource, counter;

    resource = 'foo';
    counter = 0;

    getResource = function () {
        return resource + ' has been accessed ' + (++counter) + ' times';
    };

    return getResource();
};

In the code above, a getResource function is defined. When the function is called the first time, resource and counter are created to store important information which is needed in future calls to getResource.

The function which immediately follows redefines the original getResource function, but because resource resource and counter are defined in the same scope as the inner function, they remain available.

Finally, the new getResource is executed and it’s value is returned. Now any future calls to getResource will use the inner function.

Conclusion

The Lazy Function Definition pattern allows for deferred function definition as well as insuring that resources that only need to be created once, are created once.

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

This pattern was originally discovered and named by Douglas Crockford.

Motivation

By default, there is no natural data hiding functionality in the JavaScript language. As developers push the limits by continually creating more complex applications, the need for private object members becomes increasingly apparent.

Implementation

Modules are simply a standard self-invoking function who’s return value is an object of properties and methods which serve as a public API. In the example below, foo.bar is not being set to the value of the anonymous function but rather the object that is returned by the anonymous function.

foo.bar = (function () {
    var baz = function () {};
    var bif = function () {};

    return {
        'thud' : function () {},
        'grunt' : function () {}
    };
})();

foo.bar now has an object as its value which contains two methods: thud and grunt. baz and bif are not available publicly, however thud and grunt still have direct access to them through closure.

Understanding Closure

Closure is a byproduct of functional programming whereby inner functions have access to local variables defined within an outer function, even after the outer function has returned.

There are several important facts to understand:

1. Functions can contain other functions, just like any other variable. These are inner functions.
2. Anything not returned by the outer function will not be directly available, however it still exists and is available to any inner functions that shared the same scope.

Conclusion

With the ability to implement public and private members in an API, developers now have the ability to create robust APIs in JavaScript. This allows developers to create powerful applications while exposing only what is necessary to make it function.

The Module also introduces the concept of closure. This is an extremely powerful concept of JavaScript which is a result of its functional nature. Future patterns in this series will make heavy use of closure in order to better understand its power and to show the various ways it can be applied.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

Load time configuration is also known as load time branching.

Motivation

The primary motivation behind load time configuration is to optimize conditional operations such as generating XMLHttpRequest instances or adding event listeners. Since both operations vary amongst clients, specific conditions must be checked before proceeding. The load time configuration pattern runs once at load time and sets the resulting value so that it doesn’t need to be checked again.

Implementation

The most common technique for implementing load time configuration is by way of a Self-invoking function which returns the correctly configured value.

The example below demonstrates how load time configuration can be used to normalize getting an XMLHttpRequest object.

var getXHR = (function () {
    if (window.XMLHttpRequest) {
        return function () {
            return new XMLHttpRequest;
        }
    }
    else if (window.ActiveXObject) {
        return function () {
            /* Msxml2 and Msxml3 checkes have been omitted
             * for simplicity's sake */
            return new ActiveXObject('Microsoft.XMLHTTP');
        }
    }
})();

First, a getXHR variable is declared and it’s value is being assigned by the self-invoking function that follows. Upon execution, a conditional is run which determines the correct method of obtaining an XMLHttpRequest object. When a match is found, a wrapper function is returned and stored as the value for getXHR variable.

Conclusion

The load time conditional pattern is used to configure a conditional value at load time. The result is a fully optimized value, specific to the the environment in which it is to be used.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

Self-invocation (also known as auto-invocation) is when a function executes immediately upon it’s definition. This is a core pattern and serves as the foundation for many other patterns of JavaScript development.

Motivation

The primary motivation behind self-invoking functions is to create scope. In JavaScript, only functions have scope. Any time variables are defined outside of a function, they are carelessly dumped into the global object.

Implementation

A self-invoking function is a standard function, just with a set of parentheses appended to the end.

function () {
    var foo = 'Hello';
    var bar = 'world';
    var baz = [foo, bar];
    alert(baz.join(', '));
}();

The above example defines an anonymous function. This creates a literal function, yet since no name is attributed to it, the value is never stored. The trailing parenthesis tell the function to execute, just as if you were calling a named function.

Upon execution, the above function creates three variables, formats them, and alerts them to the user. Once the function terminates, the variables are discarded and the global object remains unchanged.

Distinguishing from Actual Functions

Given the oddness of the pattern (and lack of widespread understanding), it is very possible for developers to misinterpret this pattern as an actual function. It it recommended that an extra set of parentheses wrap the function definition as well so to provide a visual clue to the developer that the function isn’t a normal function. The result would be as follows.

(function () {

    var foo = 'Hello';
    var bar = 'world';
    var baz = [foo, bar];
    alert(baz.join(', '));

})();

Passing Parameters

In the event where a self-invoking function requires parameters, they can be passed in the same manor that you would a regular function.

The following example applies an “negative” class on every input element who’s numeric value is below 0.

(function (elements) {

    for (var i = 0; i < elements.length; i++) {
        if ((elements[i].value * 1) < 0) {
            elements[i].className = 'negative';
        }
    };

})(document.getElementsByTagName('input'));

Executing in Another Scope

Even though the function is executing within its own local scope, the this keyword will still refer to the global object.

The following example uses the Function.call() method to execute a self-invoking function within the scope of the first table element on the page.

(function (elements) {

    for (var i = 5; i < this.rows.length; i++) {
        this.rows[i].className = 'hide';
    }

}).call(document.getElementsByTagName('table')[0]);

Conclusion

In an effort to protect the global object, all JavaScript applications should be written within a self-invoking function. This will create an application scope in which variables can be created without the fear of them colliding with other applications.

If a global variable is needed, developers must take the extra step by setting them directly within the window object. For example window.foo = ‘bar’;.

Self-invocation is a fundamental pattern of professional JavaScript development. Nearly every pattern in this weeks catalog uses it as a base to create scope, closure, or to configure cross-platform objects on-the-fly.

Stay tuned folks. This will be a good week.

Posts in this Series

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition

This was my first presentation at NYPHP. It was also the first time I ever went to a formal meeting where we didn’t just network and drink beer (although there was plenty of that following the presentation).

You can view or download the presentation at Slideshare. I also have the sample code which I used to demonstrate my concepts.

Enjoy.

Part Three: Events

| View | Upload your own

Part Four: Writing JavaScript Applications

| View | Upload your own

Other Posts in this Series

• JavaScript From Scratch: Parts One and Two

Update: In my code example below, I make use of a self variable. This probably isn’t the best idea in hindsight since JavaScript reserves self as a secondary reference to window.

I’m always fascinated by the JavaScript language. What impressed me most, almost a year ago, was my discovery of Douglas Crockford’s module pattern. This was my first taste of what I consider to be the most intriguing thing in programming: closure. I didn’t understand the concept of closures when I first saw it, but after getting deeper and deeper into the language, it finally clicked. At that point I realized the potential of this type of language.

A few days ago, Peter posted his list of JavaScript warning words. To my surprise, “this” made the list.

Don’t get me wrong, I’m well aware of JavaScripts scoping issues, but it was still startling to see such a common element of my code sitting next to words like with, void, and eval.

He’s right though. If you’re not careful, “this” could quickly become problematic. For example, a constructor method declared without “new” would result in “this” being a reference to window and not the newly created object… oops.

This also becomes a problem when you use “this” in callbacks used for events. When methods are applied as event handlers, “this” generally refers to the element on which the event was applied — not the object that the function lives in when you write the code.

Peter advocates the use of closure as a means to reduce dependency on “this.” Today, I discovered an interesting pattern which does just that. Instead of relying on the ambiguous “this”, the following code creates a “self” variable in the module which is available in the inner functions as a replacement for “this”.

var mikeg = function () {
    /* Create an internal reference to self as a replacement for this */
    var self = {};

    /* Return out self and some methods which have access to itself */
    return self = {
        SomeConstructor : function () {
            console.log(window !== this);
            console.log(self === mikeg);
        },

        someCallback : function () {
            console.log(window !== this);
            console.log(self === mikeg);
        }
    };
}();

It seems so obvious now that my fingers have found their way toward this code, but then again, isn’t that always the case? Looking back, I’m sure I’ve seen this elseware, but much like my original discovery of the Module, it didn’t click until after a little while.

This whole series presents a basic set of knowledge that I think any front-end developer should know.

Part One: Getting Your Feet Wet

This talk talks about the four basic building blocks of programming: variables, conditionals, loops and functions.

| View | Upload your own

Part Two: Playing With Data

This talk details the data types available in JavaScript applications. Strings, Numbers, Booleans, Arrays, and Objects are discussed. Functions as values has been omitted until a later talk.

| View | Upload your own

If you want to see me speak, see if you can get your boss to pay for your fare. The lineup for the recent AJAXWorld East was pretty phenomenal (Doug Crockford gave the keynote… need I say more?) and I’m certain this event will be even better. If you can’t get your boss to flip the bill, submit a proposal. At the time of this writing the CFP is still open.

For those of you who are interested, my session abstract is as follows:

The Beauty of JavaScript

JavaScript is one of the most interesting and misunderstood programming languages in common use today. Most developers will go their entire careers without realizing its full potential. It’s not often that you get a language that supports the feature set that JavaScript does, while still being as widely deployed. This talk will spotlight some some patterns surrounding JavaScript’s most elegant features such as closures, lambdas, object and array literals, object prototypes, private members and dynamic scope resolution — all without boring you to tears.

Using the view as a starting point may seem odd at first considering the view-related actions are some of the last steps in the page load scenario, but since our views don’t have any external dependencies, unit tests are very easy to write and so is the accompanying code.

Views in an MVC are responsible for everything presentational. This means that if it gets sent to the browser, it is the view’s job to handle it. Views must also also incredibly versatile. For example: if a client makes a request and asks for JSON instead of the default HTML, the framework should be able to accommodate this request. Likewise, if the client prefers to consume XML data, it should be able to handle that as well. Furthermore, views shouldn’t be confined to just a web-based output. There’s no reason why we couldn’t use the majority of our code to build a command-line application.

The code presented in this article will cover views that emit raw (serialized) PHP, JSON, XML, and HTML. We’ll start by looking at the functions which make up the core API to be shared by all view classes. Both an interface and an abstract class are provided for an example implementation. Following that, examples of concrete views will be demonstrated to show the flexibility of this method of handling views.

How Views Work

The easiest way to understand views is to think of them as classes whose sole purpose is to render data. A view’s core API consists of only a few simple methods which allow for data to be manipulated and also a method which renders it out to the client.

During the execution stage of the page load scenario, the controller will populate the view’s internal data store with data from the model. Having its own data independent from that of the model’s allows it to be restructured, modified, escaped, etc. without destroying the original data.

The View Interface

The code that follows defines an interface which is to be implemented by all view classes. Any components that interact with view classes will expect these methods.

interface Panda_View_Interface
{
    public function getVar($name);
    public function setVar($name, $value);
    public function unsetVar($name);
    public function getData();
    public function setData(array $data);
    public function setEchoOutput($bool);
    public function render();
}

The getVar, setVar, unsetVar, getData and setData methods all deal with modifying the view’s internal data. setEchoOutput should determine whether or not the view will be sent directly to the client, or just returned as a string. render, of course, should do the processing and rendering of the data.

The Base View Class

The following abstract class defines code for most of the methods of the interface. All concrete view classes that inherit this class will need to define the render method. Since only one method needs to be defined (generally speaking), view classes are generally short, simple, and very easy to extend or to build new ones with minimal effort.

abstract class Panda_View_Abstract
implements Panda_View_Interface
{
    protected $data = array();
    protected $echoOutput = true;

    public function getVar($name)
    {
        if (array_key_exists($name, $this->data)) {
            return $this->data[$name];
        }
        else {
            return null;
        }
    }

    public function setVar($name, $value)
    {
        return $this->data[$name] = $value;
    }

    public function unsetVar($name)
    {
        if (array_key_exists($name, $this->data)) {
            unset($this->data[$name]);
        }
    }

    public function getData()
    {
        return $this->data;
    }

    public function setData(array $data)
    {
        $this->data = $data;
    }

    public function setEchoOutput($bool)
    {
        $this->echoOutput = (bool)$bool;
    }

    protected function output($output)
    {
        if ($this->echoOutput) {
            echo $output;
        }

        return $output;
    }
}

The code above should pretty much speak for itself. The only new method added to the API was the output method, which does the actual displaying/returning of data. While defining render methods, remember to return your data through this method in order to always insure it gets rendered properly.

The Serialized PHP View

Serialized PHP is very handy for PHP clients which consume PHP services. The emitted data can quickly be imported by the client much like JSON is to JavaScript (except without the need for eval()). Serialized PHP is also popular amongst larger PHP driven organizations such as Digg, Flickr and Yahoo, each of whom use it as an output type for their web service APIs.

This is how easy it is to implement into our view library:

class Panda_View_PHP
extends Panda_View_Abstract
{
    public function render()
    {
        return $this->output(serialize($this->data));
    }
}

The JSON View

JSON has recently become the preferred data-interchange format for the web. It is most commonly consumed by JavaScript applications, however libraries exist for nearly every modern language in wide use today.

As of PHP 5.2, the json extension has been enabled by default in all installations. Much like the View_PHP class above, no processing of the data needs to take place before the render — only a single function needs to be wrapped.

class Panda_View_JSON
extends Panda_View_Abstract
{
    public function render()
    {
        return $this->output(json_encode($this->data));
    }
}

I suppose that it is worth mentioning that this method could be considered harmful for the purists in the audience (that would be all of us, right?). According to the JSON specification, JSON is built on top of two data structures: name and value pairs and an ordered list of values.

In other words, JSON emitting functions should forcefully reject any input which is not an object or an array. PHP’s native set of functions will happily accept any type of data and send it out without warning.

The XML View

Generating a basic XML document from the view data is considerably more complex that the aforementioned methods. XML documents have the potential to be tremendously complex. The code that follows takes the easy way out and completely avoids the use of attribute nodes and makes the bold assumption that only nested nodes are required to display your data. Think of this more of a proof of concept than an ideal implementation. That said, for simple data structures this should work just fine.

When therender method is called a DOMDocument is created and a loop is begun over the view’s data via the recursive method getNodes. Whenever a compound value is detected, getNodes is called again as necessary.

The name of the root node defaults to “data” and the output is assumed to be formatted. These settings may be changed by the setRootNodeName method. Also, output may be formatted or minified by passing a boolean value to the setFormatOutput method.

class Panda_View_XML
extends Panda_View_Abstract
{
    protected $document;
    protected $rootNode = 'data';
    protected $formatOutput = true;

    public function setRootNodeName($name)
    {
        $name = (string) $name;

        if (!empty($name)) {
            $this->rootNode = $name;
        }
    }

    public function setFormatOutput($bool)
    {
        $this->formatOutput = (bool) $bool;
    }

    public function render()
    {
        $this->document = new DOMDocument;
        $this->document->formatOutput = $this->formatOutput;

        $root  = $this->document->createElement($this->rootNode);
        $this->getNodes($this->data, $root);

        $this->document->appendChild($root);
        return $this->output($this->document->saveXML());
    }

    protected function getNodes($struct, DOMNode $parentNode)
    {
        if ($this->isIteratable($struct)) {
            foreach ($struct as $key => $value) {
                /* Numbers don't make good node names, use the parent's */
                if (is_numeric($key)) {
                    $key = $parentNode->nodeName;
                }

                $childNode = $this->document->createElement($key);
                $this->getNodes($value, $childNode);
                $parentNode->appendChild($childNode);
            }
        }
        else {
            $nodeValue = $this->document->createTextNode((string)$struct);
            $parentNode->appendChild($nodeValue);
        }
    }

    protected function isIteratable($struct)
    {
        return is_object($struct) || is_array($struct) || $struct instanceof Iterator;
    }
}

The HTML View

The most common output format will be HTML. My first reaction while coding the HTML view was to extend View_XML, but I quickly trashed the idea. By their very nature, HTML documents implement heavy reuse of UI components (headers, navigations, footers, etc). Of course you don’t want to store that kind of data inside the view’s data so a template system needs to be implemented.

In the old days template systems consisted of header and footer includes which wrapped a bunch of code. Frankly, I always hated the idea of managing two documents when one would do just fine. The solution I came up with was to have two types of HTML documents: templates and partials.

Templates are documents which are designed to provide HTML for the areas of a web UI which don’t change very often. In other words, this is a single-document solution to the the header and footer includes mentioned before.

Partials are page-specific HTML documents which are injected into templates at render time. The view knows where to put views by a target argument which is just an XPath location.

class Panda_View_HTML
extends Panda_View_Abstract
{
    protected $document;
    protected $template;
    protected $partials;

    public function setTemplate($template)
    {
        if (is_file($template)) {
            $this->template = $template;
        }
    }

    public function setPartial($partial, $target)
    {
        if (is_file($partial) && !empty($target)) {
            $this->partials[$partial] = $target;
        }
    }

    public function unsetPartial($partial)
    {
        if (array_key_exists($partial, $this->partials)) {
            unset($this->partials[$partial]);
        }
    }

    protected function parse($file)
    {
        $out = '';

        if (is_file($file)) {
            ob_start();

            include $file;
            $out = ob_get_contents();

            ob_end_clean();
        }

        return $out;
    }

    protected function load($source, $target)
    {
        $xpath = new DOMXPath($this->document);
        $items = $xpath->query($target);

        if ($items->length > 0) {
            $source   = $this->parse($source);
            $fragment = $this->document->createDocumentFragment();

            $fragment->appendXML($source);
            $items->item(0)->appendChild($fragment);
        }
    }

    public function render()
    {
        if (empty($this->template) || !is_array($this->partials)) {
            throw new Exception('Unable to render: incomplete view configuration.');
        }

        $templateContents = $this->parse($this->template);

        if (!empty($templateContents)) {
            $this->document = new DOMDocument;
            $this->document->loadHTML($templateContents);

            foreach ($this->partials as $source => $target) {
                $this->load($source, $target);
            }

            return $this->output($this->document->saveHTML());
        }
    }
}

Thoughts for Improvement

The motivation behind this post was to demonstrate the potential of highly abstracted views. It’s important to note that this process can and will be improved upon in future iterations. Here are a few ideas that came to mind as I was writing this post:

• More complex views (such as View_XML and View_HTML) need to be dynamically configured at runtime. Since each class has a proprietary set of properties and helper methods, it would be a good idea to have a simple configure method which accepts an array of configuration directives.
• JSON output in View_JSON should be properly handled. Because it utilizes PHP’s native json_encode, it is inherently broken. JavaScript applications have the potential to be very brittle at times so data integrity should come first.
• The View_XML class needs to be more precise. A SimpleXML-like structure would be much better suited for generating more complex XML documents.
• I feel dirty every time I look at code that uses output buffering. I still don’t like the idea that View_HTML uses it to parse partials before they are injected into the document. A much more elegant solution would be to emit raw XML data and to have the client transform it into HTML via XSLT. The downside to this method would be that it assumes the client supports XSLT, which just doesn’t fly. You could transform the XML on the server-side, but that could be overkill for most implementations.

Conclusion

So there you have it. One interface, one abstract class and four distinct output formats coming in at just over 200 lines of code.

You can download the code above via SVN by checking out the following URI:
http://panda-php.googlecode.com/svn/trunk/Panda/View/

As always I welcome your comments on this article.

Other Posts in this Series

• Part I: Introduction
• Part II: The Page Load Scenario
• You are currently reading Part III: The View