{"_id":"applitude","_rev":"33-092c7788ea0e40da47a1a6f74555f197","name":"applitude","description":"Simple Module Management","dist-tags":{"latest":"0.6.11"},"versions":{"0.1.4":{"name":"applitude","version":"0.1.4","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"odotjs":"~0.1.x","eventemitter2":"~0.4.x","jquery-browserify":"~1.7.x"},"devDependencies":{"tap":"~0.2.4"},"engines":{"node":"~0.8.x","npm":"~1.1.x"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\nView the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\n\n## A Simple Applitude Module\n\n*Tip:* Wrap your module with an Immediately Invoked Anonymous Expression (IIFE), and pass applitude into it to create a handy 'app' shortcut in your code:\n\n    (function (app) {\n      'use strict';\n    \n      /**\n       * uniqueId\n       * returns a short random string, prepended with epoch time\n       * converted into a short sequence of characters.\n       * \n       * @return [String] \n       */\n      app.register('uniqueId', function uniqueId() {\n        return (new Date().getTime() << 0).toString(36)\n            + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n      });\n    \n    }(applitude));\n\n## Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n### Options\n\nIt will also look for a beforeRender array of promises. If passed, no modules will render until all beforeRender promises have resolved.\n\nAny other options will be made available on the `app.options` object. Here's a sample:\n\n    (function (app) {\n      var namespace = 'applitudeTest',\n        whenAppInitFinished = app.deferred();\n    \n      app(namespace,\n        {\n          debug: true\n        },\n        {\n          beforeRender: [whenAppInitFinished.promise()],\n          optionAdded: true,\n          whenAppInitFinished: whenAppInitFinished\n        });\n    }(applitude));\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n* **Namespacing**. Modules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n        // A module to generate short unique ID strings...\n        app.register('uniqueId', function uniqueId() {\n          return (new Date().getTime() << 0).toString(36)\n              + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n        });\n\n\n        // elsewhere...\n        test('Applitude namespacing', function () {\n          equal(typeof app.uniqueId(), 'string',\n            '.register() should work with functions.');\n    \n          app.register('uniqueId', function () {\n            return false;\n          });\n    \n          equal(typeof app.uniqueId(), 'string',\n            '.register() should throw an error on duplicate register.');\n        });\n\n* **A sandbox** to access libraries through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n* **Loading performance boost**. Loading data blocks data rendering, so it makes sense to load data as early as possible using non-blocking means in order to render it as quickly as possible. Applitude decouples data loading from data rendering via .load() and .render() methods. .load() runs as early as possible, and .render() runs only after page ready and beforeRender have both finished.\n\n* **beforeRender** is a list of promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\n        var whenModuleReady = app.deferred();\n  \n        app.register('testModuleBeforeRender', {\n          beforeRender: [whenModuleReady]\n        });\n\n* **Environment**. A canonical place to store application environment variables -- things like urls for development, staging, or production servers, etc... You can pass an environment object into the app in the initial applitude call.\n\n* **Mixins**. Each module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list... in other words, for collisions, the last mixin wins.\n    \n        \n        test('Applitude mixins', function () {\n          app.register('aMixin', {\n            foo: 'foo',\n            bar: 'bar'\n          });\n          app.register('usesMixin', {\n            bar: 'baz',\n            mixins: 'aMixin'\n          });\n        \n          equal(app.usesMixin.foo, 'foo',\n            'Register should pull in module mixins.');\n        \n          equal(app.usesMixin.bar, 'baz',\n            'Modules should be able to override mixins.');\n        \n          equal(app.aMixin.bar, 'bar',\n            'Original mixin should not be modified by override.');\n        });\n\n* **Deferred utilities** - Applitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). Applitude exposes a few Deferred utilities, including `.resolved` (a resolved promise), `.rejected` (a rejected promise), `.when()` (a utility that allows you to run callbacks only after all promises passed to it are resolved), and `.queue()`, like `.when()`, but you can add promises to the wait queue at any time. The promise returned by `.queue()` resolves when all of the promises in the queue are resolved. These utilities can be helpful for coordinating asynchronous events in your application.","_id":"applitude@0.1.4","dist":{"shasum":"1bcd1a1b96274d142008ce995c376030780f926e","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.1.4.tgz","integrity":"sha512-wc4vHi6horuyJenWDpeo3AYOPdBdwBHyoL5V1Gs+6r9GhC304PtPsLRqALB7Z2Zl7Z+H6yKAk/Rdq8vBmtTD/Q==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBnghv0HW5u6tB5QWwOfU4gpPgsA3CeddT/xN9+6OKtMAiEAjnw2CD/Ql/gJiVuvvg+LMOdhunOUiqHeMlIbx9nlfoE="}]},"_npmVersion":"1.1.49","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.3.0":{"name":"applitude","version":"0.3.0","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x","fs-extra":"~0.1.x"},"devDependencies":{"tap":"~0.2.4"},"scripts":{"postinstall":"node ./scripts/install.js"},"engines":{"node":"~0.8.x","npm":"~1.1.x"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\nView the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\n### Loading and Rendering\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\n\n### beforeRender \n\nbeforeRender is a list of promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\n    var whenModuleReady = app.deferred();\n\n    app.register('testModuleBeforeRender', {\n      beforeRender: [whenModuleReady]\n    });\n\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\nIt will also look for a beforeRender array of promises. If passed, no modules will render until all beforeRender promises have resolved.\n\nAny other options will be made available on the `app.options` object. Here's a sample:\n\n    (function (app) {\n      var namespace = 'applitudeTest',\n        whenAppInitFinished = app.deferred();\n    \n      app(namespace,\n        {\n          debug: true\n        },\n        {\n          beforeRender: [whenAppInitFinished.promise()],\n          optionAdded: true,\n          whenAppInitFinished: whenAppInitFinished\n        });\n    }(applitude));\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utulities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* A selector engine for dom utulities as `app.$()`.\n* `app.isArray()`\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.uid()` returns a short random string suitable for unique ids\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/).\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n* `.queue()` - like `.when()`, but you can add promises to the wait queue at any time.\n\nThese utilities can be helpful for coordinating asynchronous events in your application.","_id":"applitude@0.3.0","dist":{"shasum":"6b5ff259be551a6badcc8dc44384800133ec34f8","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.3.0.tgz","integrity":"sha512-53BRfaj7jtL0pdhlT3FHKiUO6lJovmtPaaGdUjRY9+xnNPci9JdGsTYKIdseG4+apOsMzFqZlv+4cG7QHJ1iuQ==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIE6v4cEXb25FR26xXOJfismvUwtgXc4tmWjHjuh5MteaAiEAsrQ+su4Q7j7Ph3k9PF54b9h5pIP+t4iRk7IXZX2UrcM="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.3.1":{"name":"applitude","version":"0.3.1","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x","fs-extra":"~0.1.x"},"devDependencies":{"tap":"~0.2.4"},"scripts":{"postinstall":"node ./scripts/install.js"},"engines":{"node":"~0.8.x","npm":"~1.1.x"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\n### Loading and Rendering\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\n\n### beforeRender \n\nbeforeRender is a list of promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\n    var whenModuleReady = app.deferred();\n\n    app.register('testModuleBeforeRender', {\n      beforeRender: [whenModuleReady]\n    });\n\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\nIt will also look for a beforeRender array of promises. If passed, no modules will render until all beforeRender promises have resolved.\n\nAny other options will be made available on the `app.options` object. Here's a sample:\n\n    (function (app) {\n      var namespace = 'applitudeTest',\n        whenAppInitFinished = app.deferred();\n    \n      app(namespace,\n        {\n          debug: true\n        },\n        {\n          beforeRender: [whenAppInitFinished.promise()],\n          optionAdded: true,\n          whenAppInitFinished: whenAppInitFinished\n        });\n    }(applitude));\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.uid()` returns a short random string suitable for unique ids\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n* `.queue()` - like `.when()`, but you can add promises to the wait queue at any time.\n\nThese utilities can be helpful for coordinating asynchronous events in your application.","_id":"applitude@0.3.1","dist":{"shasum":"c772a6ca2bb5aab76a88b074b1814d27d8c3e04d","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.3.1.tgz","integrity":"sha512-aKrbI1ddOQCElNOQy/0Z6GRwn/jA3fkDQ6A3ZttTaalqmxI16K52yDcRIZlVCtVoZfsaIc3yMS5QaWdWtD6z0w==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICUvi2DT8gsYXHVKSeFqxIG78fE1ZefQFOsad+NJmqXlAiBrSkfGJYD1KIfGN/i7GIyeW1WKhhBDJSJ9UHGpSyT8CA=="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.5.1":{"name":"applitude","version":"0.5.1","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"grunt":"~0.3.x","eventemitter2":"~0.4.x","odotjs":"~0.2.x","fs-extra":"~0.1.x"},"scripts":{"postinstall":"node ./scripts/install.js","test":"grunt"},"engines":{"node":"~0.8.x","npm":"~1.1.x"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.","_id":"applitude@0.5.1","dist":{"shasum":"6529607d841c51168b3851546eaab1fc72b27456","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.5.1.tgz","integrity":"sha512-JIrnuukCYSNt2Y0CODnppk9ch3YP6tA4RX0ZL0SG43+ct1kqKTJ0WZRDi3eNmB7qqGFYyW52Y5q9W2ZqCD42Tg==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIDeKh5f316+B+zl04RGI/0HZ9XoiQCqpbZAzLJC4nwqrAiB0dw9RVXcohzTIeI1a8CMib8DyjDvmoCgOCY4ib++Lgg=="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.0":{"name":"applitude","version":"0.6.0","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"grunt":"~0.3.x","eventemitter2":"~0.4.x","odotjs":"~0.2.x","fs-extra":"~0.1.x"},"scripts":{"postinstall":"node ./scripts/install.js","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        app.exports = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.0","dist":{"shasum":"21e09fe624244e534fac2d654606e14ee1e05b33","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.0.tgz","integrity":"sha512-qi1YW7+5y3nY6LvW7crw7l7v7E5m2Lffn2ymYZdLyUifAJKyNlOqMfE9tJ2WXD3VtLGr6spBrnCW1+2Q1nUaTA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIHyLd8MUIpezqHHAD1PEFjAdxuJwrNS6ah7QKT2CVuFMAiEAjsR5mirtK2OdznU/3vZ2sXwSXWDEU1WdV9ucpX3dS8U="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.1":{"name":"applitude","version":"0.6.1","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"lib":"./lib","test":"./test"},"dependencies":{"grunt":"~0.3.x","eventemitter2":"~0.4.x","odotjs":"~0.2.x","fs-extra":"~0.1.x"},"scripts":{"postinstall":"node ./scripts/install.js","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.1","dist":{"shasum":"26482e7ff4567bf9179926ff420fbbe14a868d0d","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.1.tgz","integrity":"sha512-v9JM8Cdq7CN7A44HWv72FkMwRJaK2HrinZa/AMPfDwWOyzA86hmr2QOnVRxVGu1mz40rwV6RTPF4HlN8zNTD5A==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDQ3KliADI4sxcPfBQiTv8QwlYev3jT/Z4jLtX1h1AQcAiEA5Q042ejrByUlUb83yknI9clc46dbiiEyL0p9+vImUnI="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.2":{"name":"applitude","version":"0.6.2","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"grunt":"~0.3.x","eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.2","dist":{"shasum":"4dbee83a83b6a2dbc9fc5f446f9a563e8a5ef688","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.2.tgz","integrity":"sha512-9JR9f34KlF87iZJZZbTKmoQ+x+9NJqmJq//bOHC1h0hzxeNIX9q67K1chm0dHjIK0IPS1YNLZFKg7QVgz4tLrQ==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCvKEQOzMVMHIa0wsGQhIHzXHPmNQUXPjYeAvYg+4LxEQIhAK9CLqlF0wNmFY/OcYq+L4qP7cBZKQyY4vJ8n/JtBVgL"}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.4":{"name":"applitude","version":"0.6.4","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.4","dist":{"shasum":"f4d7c5465d6abf71cce99bb26b722f6eb9e47b9e","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.4.tgz","integrity":"sha512-FTAprllEKks6/VmDGD6CiptY5Gl2Bu5+lQYjb1XOcteyQ0rzO+wysgs2nJxEjWwp9uZ232vdzUmXxsRfr0iUmA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIHm0alOGaRaA5MIWKXODCwLDK/hhBwjWsGpSOkmLjMOgAiEA4jnYMIkPH+duKi8BphdMnRP8SLSKFf7holJF0EMM2v0="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.5":{"name":"applitude","version":"0.6.5","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.5","dist":{"shasum":"c75140744b5425c0c1ce023d9ea962ce6233e2ab","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.5.tgz","integrity":"sha512-Vvr0WaZCU15mbEFsUk9gYKaadfTlZUQ97KSxf5meIKuqrlG1iafyKh9NrRpyGnekw8sJ0b6rRQQ61XEVLydxGg==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIHDehU/Vtio/HESSjFzRgxzQ2tIXTb6DwIkrp1rJZ8DJAiEAskB3jsfIXp2KKsoGiM2Q2wrCcJRnPDpxIKU4HhJ1UYo="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.6":{"name":"applitude","version":"0.6.6","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.6","dist":{"shasum":"cb21161235afcc414fb4ed275365a6f6452f60b2","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.6.tgz","integrity":"sha512-+k+nMFS5BpVTTH/AYGwJHuvDP4QUlpv/ia6s8Uqubzk+AsCpYqTX7gH/X/Yi6j0kItG5gwoJ+/0H2cxxrS2IGA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDIksIgmJ9o68IlWXqE2VNZatCw5mzsnLzbOsJBONB7EgIgRiUVOEeAXnHcJOMeOER4rli0fBqiUvfwhxZzuejjru4="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.7":{"name":"applitude","version":"0.6.7","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt test"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.7","dist":{"shasum":"81fe16d6057af58847ebf2a526b497427df70517","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.7.tgz","integrity":"sha512-IVmsNowhDX+Dw7ZMX6YGAKd0PGCABgiwnfJSJU43NWArRoR8F2eB2DfWqf0PVqw0fjUR6ft1uwwfEwQOyKPOOA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCID4KtCg8/FFgNy7BPux0elS1lWFoC5jopLkHIfAC7ewRAiBqKggOp8miJ8AtpNK+OYx3XZ2Dp2ih5HH9loAVOMMyEA=="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.8":{"name":"applitude","version":"0.6.8","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt test"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.8","dist":{"shasum":"a61896b61e7f637856679f1c14c5d5319874a503","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.8.tgz","integrity":"sha512-6h9HMCR8DqLCtkudYzY20NbSXWGOr95ZQcbllrZd2Dn7+QGUnbTlvnYkN7AqhYviFKLewlpUzVq8OKOSBFgdvw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBUd4Op7YIQCj67+CwqsVmPbptoRbNrjsvl/dcUH97FmAiB9+5Oo9ruulwmL0VSWF6m2DM7ENjIbJjkxNxIRnGHPKA=="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.9":{"name":"applitude","version":"0.6.9","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt test"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.9","dist":{"shasum":"87c18b78491fa2c22fe866f440edd5148807c120","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.9.tgz","integrity":"sha512-x/kqtV9ozTJeX2NBQi+TL63ciBldhehE8KqPpNJumIx2QKuP+hxnCDSW6FM3FIPCtsg1aPIfbgPmM5TLGGvgBw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIF0ejbC5D8xNSeFqY6b4AEb6cZtY9Lrj3kH/PmQ9FvRCAiBZPYUuhjXJxIp46vGUTVx5OgKfSHboUV6lDkQPuKbCBw=="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.10":{"name":"applitude","version":"0.6.10","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"grunt":"~0.3.x","eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"scripts":{"postinstall":"grunt","test":"grunt test"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.10","dist":{"shasum":"ad610050af56d49c91b888fa43fb1eb7f7e34ec1","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.10.tgz","integrity":"sha512-J3LZnjCB3rff4jSgyQeT0tyNZq3ml+YyypfbNdeKXceDLE+82wnuxk2Co/bQUCEdvj0Xsz8UoZEJhKw/IzHG7w==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQD5Pure2fR0d4/RVV6ct6/1b8GgM/2WMifuu7vbu8cAdAIhAKNG+oY2NE/IhO5t7demtXLj47+b6q8e+2C/mm5mDIp5"}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]},"0.6.11":{"name":"applitude","version":"0.6.11","description":"Simple Module Management","author":{"name":"Eric Elliott","url":"http://ericleads.com"},"main":"./dist/applitude.js","keywords":["module","modules","architecture","client","browser","events"],"repository":{"type":"git","url":"https://github.com/dilvie/applitude"},"directories":{"dist":"./dist","examples":"./examples","lib":"./lib","src":"./src","test":"./test"},"dependencies":{"eventemitter2":"~0.4.x","odotjs":"~0.2.x"},"devDependencies":{"grunt":"~0.3.x"},"scripts":{"test":"grunt test"},"engines":{"node":"*","npm":"*"},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\n# **View the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)**\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\nApplitude was created to illustrate how to implement a client-side JavaScript application architecture for the upcoming book \"Programming JavaScript Applications\" (O'Reilly).\n\n## Who's Using Applitude?\n\n* [Tout](http://tout.com/)\n* [Your company here](https://github.com/dilvie/applitude/issues/new?title=Add+Me+to+the+Applitude+User+List) - Drop me a note if you're using Applitude.\n\n## Getting started\n\n    $ git clone git://github.com/dilvie/applitude.git\n\nIf you already have the dependencies ready, just drop `applitude/dist/applitude.js` into your project's lib folder and include it in your HTML build after the dependencies have loaded.\n\nIf you need the dependencies as well, you can use npm to pull them in (with the exception of jQuery). They will be installed in `applitude/lib/`.\n\nIf you don't have node installed, you can download it from `http://nodejs.org/download/`.\n\n    $ cd applitude\n    $ npm install\n\n### Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Create your first applitude module\n\nFirst you'll need an IIFE (Immediately Invoked Function Expression) for encapsulation:\n    \n    (function (app) {\n        // your code here\n    }(applitude));\n\n\nAnd a namespace:\n\n    (function (app) {\n      // namespace should be a var\n      var namespace = 'hello';\n    }(applitude));\n\n\nProvide an API:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      //..\n\n    }(applitude));\n\n\nRegister your module:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'hello',\n        api;\n    \n      function hello() {\n        return 'hello, world';\n      }\n    \n      api = {\n        hello: hello\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nYou might be tempted to create shortcuts like:\n\n\n    (function (app) {\n      'use strict';\n    \n      app.register('hello', {\n        hello: function () {\n          return 'hello, world';\n        });\n\n    }(applitude));    \n\nHowever, once you get into the Applitude groove, you'll be using a lot of events, and declaring a namespace lets you do things like this:\n\n    app.trigger('some_action.' + namespace, eventData);\n\nThen, if you need to move responsibilities from one module to another, or change the name of your module, you don't have to change any of this code.\n\nAlso, declaring your API explicitly makes it immediately clear which parts of your module constitute the exposed interface:\n\n      api = {\n        hello: hello\n      };\n\nIn this case, it's just `hello`, but most interfaces will be more complicated. This is also a great clue about what you need to write tests for. If it's not in the API, don't write tests for it. You should be testing that your interface conforms to the contract.\n\nWhen you declare you're API, you're making an implied guarantee that users can safely use the attributes exposed on that API, so you need to write unit tests to be sure that's the case.\n\n\n### Loading and Rendering\n\nModule initialization is broken into two phases:\n\n#### Load\n\nThe first is the load phase. Your `.load()` method is called by Applitude as soon as your script is evaluated and the `app.register()` method is called.\n\n#### Render\n\nThe `.render()` method is called after:\n\n1. all `.beforeRender` callbacks have fired, and\n1. the DOM is ready to be manipulated\n\nIf you need to fetch some data asynchronously before you render your module, Applitude helps speed things up by launching your asynchronous calls as early as possible. Just load your data in the `.load()` method. For example, grab Skrillex info from BandsInTown:\n\n    (function (app) {\n      'use strict';\n      var namespace = 'skrillexInfo',\n        api,\n        data,\n        whenLoaded;\n    \n      function load() {\n        var url = 'http://api.bandsintown.com/artists/Skrillex.' +\n        'json?api_version=2.0&app_id=YOUR_APP_ID';\n\n        whenLoaded = app.get(url);\n        whenLoaded.done(function (response) {\n          data = response;\n        });\n\n        return whenLoaded.promise();\n      }\n\n      function render() {\n        // do something with data at render time.\n      }\n    \n      api = {\n        load: load,\n        render: render\n      };\n    \n      app.register(namespace, api);\n    }(applitude));\n\nTip: Try not to do anything blocking in your `.load()` method. For example, you might want to fetch the data that you need to complete your page render, but if you're loading a fairly large collection and you need to iterate over the collection and do some data processing, save the data processing step for `.render()` time, when you're not blocking the page render process.\n\n*Note that you cannot manipulate the DOM at all in your `.load()` method.*\n\n## Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n## Options\n\n### beforeRender\n\nbeforeRender is a list of application-level promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\nYou can resolve beforeRender promises by listening for an expected event to fire:\n\n    (function (app) {\n      var whenI18nLoaded = app.deferred();\n\n      app.on('translations_loaded.i18n', function () {\n        whenI18nLoaded.resolve();\n      });\n\n      app('hello', {\n          debug: true\n        },\n        {\n          beforeRender: [whenI18nLoaded.promise()],\n          optionAdded: true\n        });    \n    }(applitude));\n\nLater:\n\n    whenTranslationsLoaded.done(function () {\n      app.trigger('translations_loaded.' + namespace);\n    });\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n## Sandbox\n\nAccess libraries and utilities through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n### Included utilities\n\n* `app.$()` - A selector engine for dom utulities\n* `app.isArray()` - returns true if the argument is an array\n* `app.stringToArray()` transforms `'a, string'` to `['a', 'string']`\n* `app.o()` provides a [prototypal oo libarary called odotjs](http://dilvie.github.com/odotjs/)\n\n\n## Namespacing\n\nModules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n    // A module to generate short unique ID strings...\n    app.register('uniqueId', function uniqueId() {\n      return (new Date().getTime() << 0).toString(36)\n          + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n    });\n\n\n    // elsewhere...\n    test('Applitude namespacing', function () {\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should work with functions.');\n\n      app.register('uniqueId', function () {\n        return false;\n      });\n\n      equal(typeof app.uniqueId(), 'string',\n        '.register() should throw an error on duplicate register.');\n    });\n\n\n## Mixins\n\nEach module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list.\n\n    test('Applitude mixins', function () {\n      app.register('aMixin', {\n        foo: 'foo',\n        bar: 'bar'\n      });\n      app.register('usesMixin', {\n        bar: 'baz',\n        mixins: 'aMixin'\n      });\n    \n      equal(app.usesMixin.foo, 'foo',\n        'Register should pull in module mixins.');\n    \n      equal(app.usesMixin.bar, 'baz',\n        'Modules should be able to override mixins.');\n    \n      equal(app.aMixin.bar, 'bar',\n        'Original mixin should not be modified by override.');\n    });\n\n## Deferred utilities\n\nApplitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). \n\nApplitude exposes a few Deferred utilities, including:\n\n* `.resolved` - a resolved promise\n* `.rejected` - a rejected promise\n* `.when()` - a utility that allows you to run callbacks only after all promises passed to it are resolved\n\nThese utilities can be helpful for coordinating asynchronous events in your application.\n\n\n## Writing Applitude-Compatible Library Code\n\nIf you want to write general-purpose library modules that you can use with or without Applitude (including Node support), this pattern might help:\n\n    // Shim support for CommonJS variables. This greatly reduces logic needed.\n    var global = global || this, module = module || undefined;\n    \n    (function (app) {\n      'use strict';\n    \n      // replace the namespace string with the name of your library\n      var namespace = 'librarymodule',\n\n        // replace this api with your library code\n        api = {\n          foo: function () {\n            return 'foo';\n          }\n        };\n\n      // don't change anything from here down.\n      if (app.register) {\n        app.register(namespace, api);\n      } else {\n        namespace = app.exports ? 'exports' : namespace;\n        app[namespace] = api;\n      }\n    \n    }(global.applitude || module || this));\n\n\nAt the bottom of the Immediately Invoked Function Expression (IIFE), you attempt to pass in applitude if it exists. Otherwise, pass in either the CommonJS `module` (for Node), or `this`.","_id":"applitude@0.6.11","dist":{"shasum":"edb081ca76b6c8e5de5489e562221a1d5701fc01","tarball":"https://registry.npmjs.org/applitude/-/applitude-0.6.11.tgz","integrity":"sha512-DIfBc9wveJFLyuHJwUMb9Tma35O4ZcUAkEur4/MGWgXDGgDB10thFB6LraxMqV8OPeFhRla1YB2r12c5T+apQQ==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCICUfhx7ZjgISbR6PY5m7zINYiI4+GX7HfavsyzyfItJVAiEA++aNtpvc4M/NnmCHdkUEeJjmJfW/SmfoI0R3n4Xdu3o="}]},"_npmVersion":"1.1.51","_npmUser":{"name":"dilvie","email":"dilvie@dilvie.com"},"maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}]}},"readme":"# Applitude.JS - Simple module management.\n\nApplitude is a simple event-driven client-side JavaScript application architecture and module management framework that serves the following needs:\n\n* Namespacing\n* Sandbox\n* Environment\n* Loading performance boost\n* Mixins\n* Deferred utilities\n\nView the slideshow: [\"Introducing Applitude: Simple Module Management\"](https://docs.google.com/presentation/embed?id=1BQ6s5EzLqenWZX1RCUIgVlJViKzjZAvvxN4UVkQzspo&start=false&loop=false&delayms=10000)\n\n**Status** - Developer preview (stick to tested, documented features for best results). In production use with millions of monthly active users.\nThere are [unit tests](http://applitude.herokuapp.com/) covering most of the functionality. [![Build Status](https://secure.travis-ci.org/dilvie/applitude.png)](http://travis-ci.org/dilvie/applitude)\n\nThe guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”\n\n\n## A Simple Applitude Module\n\n*Tip:* Wrap your module with an Immediately Invoked Anonymous Expression (IIFE), and pass applitude into it to create a handy 'app' shortcut in your code:\n\n    (function (app) {\n      'use strict';\n    \n      /**\n       * uniqueId\n       * returns a short random string, prepended with epoch time\n       * converted into a short sequence of characters.\n       * \n       * @return [String] \n       */\n      app.register('uniqueId', function uniqueId() {\n        return (new Date().getTime() << 0).toString(36)\n            + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n      });\n    \n    }(applitude));\n\n## Create an app\n\n    app(namespace, environmentObject, optionsObject);\n\n### Environment\n\nEnvironment is made up of things like image hosting URLs which might vary from one host or CDN to another. Generally server side environments will also contain passwords, secrets, or tokens for communicating with third party APIs. Since the client-side JavaScript environment is not secure, you should not pass those secrets through to the JavaScript layer.\n\nEnvironment variables should be passed into your application from your environment configuration, and not hard-coded. Your application should be portable to new hardware or hosts without any changes to your codebase.\n\nIt might be tempting to pass a single environment string through and put logic in your code to determine URLs and so on, but that should be done at the configuration level wherever possible. That will make it easier to port your app to new environments.\n\nAs a general rule of thumb, your app should be ready to open-source at any time, even if you never intend to do it. That mode of thought will help establish the proper separation of environment configuration and secrets from application code.\n\nApplitude expects at least one varible to be defined: `debug` (Bool) If `debug` is true, anything logged with `app.log()` will be printed to the console (if available).\n\nFor more on application configuration, see [\"The Twelve-Factor App\"](http://www.12factor.net/config)\n\n### Options\n\nIt will also look for a beforeRender array of promises. If passed, no modules will render until all beforeRender promises have resolved.\n\nAny other options will be made available on the `app.options` object. Here's a sample:\n\n    (function (app) {\n      var namespace = 'applitudeTest',\n        whenAppInitFinished = app.deferred();\n    \n      app(namespace,\n        {\n          debug: true\n        },\n        {\n          beforeRender: [whenAppInitFinished.promise()],\n          optionAdded: true,\n          whenAppInitFinished: whenAppInitFinished\n        });\n    }(applitude));\n\n## Applitude Responsibilities\n\n### Events\n\nModules should know as little as possible about each other. To that end, modules should communicate through a global event bus, supplied by the applitude sandbox. You can use `app.on()` to subscribe to events, and `app.trigger()` to publish.\n\n    app.on('a.*', function (data) { \n        console.log(data);\n    });\n    \n    // later\n    app.trigger('a.b', 'hello, world'); // logs 'hello, world'\n\nBest practice is to get specific about the events you report, and always use your modules namespace to trigger. For example:\n\n\n    (function (app) {\n        var namespace = 'videoPlayer',\n            api;\n    \n        function bindEvents() {\n            app.$('#' + namespace).on('click', '#playButton', function (event) {\n                app.trigger('click.' + namespace, event);\n            });\n        }\n    \n        // Wait for the dom to be ready before we try to \n        api = {\n            render: bindEvents\n        };\n    \n        app.register(namespace, api);\n    }(applitude));\n    \nEvents support wildcards. This way, you can implement cross-cutting concerns. For example, log every click in your app:\n\n    (function (app) {\n        var namespace = 'clickLogger',\n            api;\n        \n        app.on('click.*', function logData(event) {\n            // Implement real logging here. This just spits it into the in-memory app log.\n            app.log(event);\n        });\n        \n        function recent() {\n            // get recent log entries\n        }\n        \n        api = {\n            recent: recent\n        };\n        \n        app.register(namespace, api);\n    }(applitude));\n\n* **Namespacing**. Modules can only be registered once, in order to avoid duplicate code runs, and tricky associated bugs.\n\n        // A module to generate short unique ID strings...\n        app.register('uniqueId', function uniqueId() {\n          return (new Date().getTime() << 0).toString(36)\n              + (\"0000\" + (Math.random() * Math.pow(36, 4) << 0).toString(36)).substr(-4);\n        });\n\n\n        // elsewhere...\n        test('Applitude namespacing', function () {\n          equal(typeof app.uniqueId(), 'string',\n            '.register() should work with functions.');\n    \n          app.register('uniqueId', function () {\n            return false;\n          });\n    \n          equal(typeof app.uniqueId(), 'string',\n            '.register() should throw an error on duplicate register.');\n        });\n\n* **A sandbox** to access libraries through a canonical interface, rather than calling library code directly. Doing so allows you to modify the implementation, or swap out the library completely with transparency to the application code.\n\n* **Loading performance boost**. Loading data blocks data rendering, so it makes sense to load data as early as possible using non-blocking means in order to render it as quickly as possible. Applitude decouples data loading from data rendering via .load() and .render() methods. .load() runs as early as possible, and .render() runs only after page ready and beforeRender have both finished.\n\n* **beforeRender** is a list of promises which all must finish before .render() begins. For example, many apps will need i18n translations to load before any module is allowed to render. By adding an i18n promise to the application's beforeRender queue, you can postpone render until the translations are loaded. Using beforeRender can prevent tricky race condition bugs from cropping up, and provide a neat solution if you need a guaranteed way to handle tasks before the modules render.\n\n        var whenModuleReady = app.deferred();\n  \n        app.register('testModuleBeforeRender', {\n          beforeRender: [whenModuleReady]\n        });\n\n* **Environment**. A canonical place to store application environment variables -- things like urls for development, staging, or production servers, etc... You can pass an environment object into the app in the initial applitude call.\n\n* **Mixins**. Each module can declare a list of other modules to mix in with applitude. The new module can selectively override attributes from the mixed-in modules. The mixins later in the list will override attributes picked up from mixins earlier in the list... in other words, for collisions, the last mixin wins.\n    \n        \n        test('Applitude mixins', function () {\n          app.register('aMixin', {\n            foo: 'foo',\n            bar: 'bar'\n          });\n          app.register('usesMixin', {\n            bar: 'baz',\n            mixins: 'aMixin'\n          });\n        \n          equal(app.usesMixin.foo, 'foo',\n            'Register should pull in module mixins.');\n        \n          equal(app.usesMixin.bar, 'baz',\n            'Modules should be able to override mixins.');\n        \n          equal(app.aMixin.bar, 'bar',\n            'Original mixin should not be modified by override.');\n        });\n\n* **Deferred utilities** - Applitude relies on promises and deferreds from the jQuery library (along with other jQuery goodness, such as the page ready function). Applitude exposes a few Deferred utilities, including `.resolved` (a resolved promise), `.rejected` (a rejected promise), `.when()` (a utility that allows you to run callbacks only after all promises passed to it are resolved), and `.queue()`, like `.when()`, but you can add promises to the wait queue at any time. The promise returned by `.queue()` resolves when all of the promises in the queue are resolved. These utilities can be helpful for coordinating asynchronous events in your application.","maintainers":[{"name":"dilvie","email":"dilvie@dilvie.com"}],"time":{"modified":"2022-06-13T03:18:53.398Z","created":"2012-08-18T09:11:15.621Z","0.1.4":"2012-08-18T09:11:17.099Z","0.3.0":"2012-08-20T21:26:04.523Z","0.3.1":"2012-08-21T15:23:37.386Z","0.5.1":"2012-09-06T17:02:45.129Z","0.6.0":"2012-09-14T23:55:45.399Z","0.6.1":"2012-10-12T08:07:07.509Z","0.6.2":"2012-10-12T09:19:40.340Z","0.6.4":"2012-10-12T17:19:13.449Z","0.6.5":"2012-10-12T18:03:26.808Z","0.6.6":"2012-10-12T18:13:29.951Z","0.6.7":"2012-10-13T01:46:24.854Z","0.6.8":"2012-10-19T17:19:42.441Z","0.6.9":"2012-10-19T17:26:52.544Z","0.6.10":"2012-10-28T22:42:39.616Z","0.6.11":"2012-11-27T19:02:06.876Z"},"author":{"name":"Eric Elliott","url":"http://ericleads.com"},"repository":{"type":"git","url":"https://github.com/dilvie/applitude"}}