var dispatcher = _.clone( Backbone.Events );
  

// A basic shared event broker
var broker = _.clone( Backbone.Events );

var Users = Backbone.Collection.extend{{
    // reference the broker, subscribe to an event
    initialize: function(broker){
        this.broker = broker;
        this.broker.on('users:add', this.add, this);
     },
     add: function(user) {
         console.log(user.id);
     }
};

var UserEditor = Backbone.View.extend({
     el: '#editor',
     // reference the broker
     initialize: function(broker){
        this.broker = broker;
        this.$userId = this.$('#userId');
     },
     add: function() {
        // publish an event
        var user = new User({id: this.$userId().val()});
        this.broker.trigger('users:add', user);
    }
};
// ...
   

var Users = Backbone.Collection.extend{{
    broker: Backbone.EventBroker,
    initialize: function(){
        this.broker.on('users:add', this.add, this);
    },
    add: function(user) {
        console.log(user.id);
    }
};

var UserEditor = Backbone.View.extend({
     el: '#editor',
     broker: Backbone.EventBroker,
     initialize: function(broker){
        this.$userId = this.$('#userId');
     },
     add: function() {
        // publish an event
        var user = new User({id: this.$userId().val()});
        this.broker.trigger('users:add', user);
    }
};
// ...
   

var Users = Backbone.Collection.extend{{
    // use the 'users' broker
    userBroker: Backbone.EventBroker.get('users'),
    initialize: function(broker){
        this.userBroker.on('add', this.add, this);
    },
    add: function(user) {
        console.log(user.id);
    }
};

var UserEditor = Backbone.View.extend({
    el: '#editor',
    // use the 'users' broker
    usersBroker: Backbone.EventBroker.get('users'),
    // also use the 'roles' broker
    rolesBroker : Backbone.EventBroker.get('roles'),
    initialize: function(broker){
        this.$userId = this.$('#userId');
    },
    add: function() {
        // publish an event
        var user = new User({id: this.$userId().val()});
        this.usersBroker.trigger('add', user);
    }
};
   

var Users = Backbone.Collection.extend{{
    // use the 'users' broker
    userBroker: Backbone.EventBroker.get('users'),
    initialize: function(broker){
        // prefix the namespace if desired
        this.userBroker.on('users:add', this.add, this);
    },
    add: function(user) {
        console.log(user.id);
    }
};

var UserEditor = Backbone.View.extend({
    el: '#editor',
    // use the 'users' broker
    usersBroker: Backbone.EventBroker.get('users'),
    // also use the unique 'roles' broker
    rolesBroker: Backbone.EventBroker.get('roles'),
    initialize: function(broker){
        this.$userId = this.$('#userId');
    },
    add: function() {
        // publish an event
        var user = new User({id: this.$userId().val()});
        // prefix the namespace if desired
        this.usersBroker.trigger('users:add', user);
    }
};
   

// Register event/callbacks based on a hash and associated context
var Users = Backbone.Collection.extend( 
{
    broker: Backbone.EventBroker,

    initialize: function() 
    {
	       this.broker.register({
	           'user:select'   : 'select',
	           'user:deselect' : 'deselect',
	           'user:edit'     : 'edit',
	           'user:update'   : 'update',
            'user:remove'   : 'remove'  
	       }, this );
    },
    select: function() { ... },
    deselect: function() { ... },
    edit: function() { ... },
    update: function() { ... },
    remove: function() { ... }å
});
  

// Register event/callbacks based on a hash and associated context
var Users = Backbone.Collection.extend( 
{
    // defines events of interest and their corresponding callbacks
    this.interests: {
        'user:select'   : 'select',
        'user:deselect' : 'deselect',
        'user:edit'     : 'edit',
        'user:update'   : 'update',
        'user:remove'   : 'remove'  
    },
    initialize: function() 
    {
        // register this object with the EventBroker
        Backbone.EventBroker.register( this );
    },
    select: function() { ... },
    deselect: function() { ... },
    edit: function() { ... },
    update: function() { ... },
    remove: function() { ... }
});
  

For additional examples, see the backbone-eventbroker project on github.

Naturally, it follows that such flexibility imparts additional responsibility on the developer. In my experience with architectural frameworks in general, and Backbone in particular, many times this kind of trade off can be quite preferable.

Extending Backbone

As mentioned above, Backbone implements the essential building blocks necessary to provide general structure within an application. If a feature is needed which is not provided by default, by design, Backbone allows for easily extending the core APIs in order to implement additional features as needed. In fact, developers are encouraged to do so.

Perhaps a good example of this can be found in the need to persist collections in Backbone; that is, interestingly, while the Backbone Model API implements a default save method, the Backbone Collection does not provide a similar API for explicitly saving the models within a collection; that is, saving the collection itself. This feature may have been left out intentionally as part of an initial design decision, as there are some complexities to saving an entire collection as a general use-case; such as saving deltas, propagating saved state to models within the collection and so forth; or, perhaps it simply may have been an oversite. Regardless of the reason, in certain scenarios it can be useful to save an entire collection rather than saving each model individually – fortunately, given the flexibility of Backbone, writing an extension to implement this feature is quite simple.

The PersistableCollection

As a basic solution for saving a Backbone Collection, I wrote a general abstraction – PersistableCollection, which extends Backbone.Collection, implementing a default save method.

The PersistableCollection API is quite simple in that it essentially just implements a proxy which wraps the collection in a Backbone Model, and ensures there is only one proxy created per collection. The url and toJSON methods, respectively, of the proxy Model reference the url and toJSON methods of the collection to which the proxy is bound. You can either extend PersistableCollection or generate a proxy for an existing collection via the static createProxy method. Examples of each follow.

Using a PersistableCollection

A PersistableCollection can be instantiated and used directly, just like a Backbone.Collection:

var users = new Backbone.PersistableCollection([
    { name: "Jane", id: 25},
    { name: "Joe",  id: 26}
], {
    url: '/users';
);
users.save(); //saves the collection
  

Extending PersistableCollection

You can extend PersistableCollection and simply invoke save to persist the models in the collection:

var Users = Backbone.PersistableCollection.extend({
    url: '/users',
    model: User
});
var users = new Users([[
    { name: "Jane", id: 25},
    { name: "Joe",  id: 26}
]);
users.save(); //saves the collection
  

Creating a proxy for an existing collection

An existing collection can be saved by creating a proxy for it:

var users = new UsersCollection([
    { name: "Jane", id: 25},
    { name: "Joe",  id: 26}
]);
users.url = '/users';

var proxy = PersistableCollection.createProxy( users );
proxy.save();  //saves the collection
  

The PersistableCollection can be used as a general extension for saving entire collections based on the representation of all models within the collection. If you are interested in extending it to account for more specific use-cases, you can simply override the default save implementation as needed.

You can find the gist for the source and spec here.

The Optimizer is quite powerful insofar that fine-grained control over various aspects of the optimization process can be implemented with relative ease. One such example is the ability to specify a callback function to be invoked for each module in the build prior to optimization. This essentially provides the necessary hooks needed to implement a preprocessor.

The onBuildWrite option

The optimize method of the RequireJS Optimizer accepts an onBuildWrite option which allows for a callback to be specified. The callback will be invoked prior to serialization of each module within the optimized bundle. Callbacks receive the name, path and contents of the module; and, are always expected to return a value.

For example, consider the following build configuration which demonstrates a basic onBuildWrite callback that simply logs the name of each module processed by the build to the console and, returns the module’s content unmodified.

var config = {
    baseUrl        : 'src',
    appDir         : '../',
    dir            : '../deploy',
    mainConfigFile : '../src/main.js',
    onBuildWrite   : function( name, path, contents ) {
    	console.log( 'Writing: ' + name );
    	return contents
    },
    modules: [{ 
    	name: 'main' 
    }],
};
requirejs.optimize( config, function(results) {...});
 

Using the above configuration, when executed against a (contrived) example consisting of just a single module, “ModuleA”, in Node, it would output the following to the console:

$ node build.js 
Writing: main
Writing: ModuleA

src/main.js
----------------
src/app/module.a.js
src/main.js
 

If we were to print out the contents of the files we would see something like this:

$ node build.js 
Writing: ModuleA
define( function() {
	return {
		name: "Module A" 
	}
});
Writing: main
require.config( {
    paths : {
        ModuleA : 'app/module.a'
    }
});
require( ['ModuleA'], function( moduleA ){...});

src/main.js
----------------
src/app/module.a.js
src/main.js
 

With this in mind, a basic preprocessor can be implemented quite easily using the onBuildWrite option. Assume the main.js script has a token placeholder for the build version like so:

/*!
 * #version
 */
require.config( {
    paths : {
        ModuleA : 'app/module.a',
    }
});
require( ['ModuleA'], function( moduleA ) {...});
 

We can implement a simple preprocessor which replaces the #version token with a build date as follows:

var config = {
    baseUrl        : 'src',
    appDir         : '../',
    dir            : '../deploy',
    mainConfigFile : '../src/main.js',
    onBuildWrite   : function( name, path, contents ) 
    {
        console.log( 'Writing: ' + name );

    	if ( name === 'main' ) 
        {
            // output the original source contents
            console.log( contents );
                
            // perform transformations on the original source
    		contents = contents.replace( /#version/i, new Date().toString() );
                
            // output the processed contents
    		console.log( contents );
    	}
        // return contents
    	return contents;
    },
    modules: [{ 
    	name: 'main' 
    }],
};
requirejs.optimize( config, function(results) {...});
 

The above onBuildWrite callback logs the original contents, replaces the #version token with the current date, logs the result and returns the processed content. The output of which would be similar to the following:

$ node build.js
Writing: main
/*!
 * #version
 */
require.config( {
    paths : {
        ModuleA : 'app/module.a'
    }
});
require( ['ModuleA'], function( moduleA ) {...});
/*!
 * Fri Mar 23 2012 23:35:17 GMT-0400 (EDT)
 */
require.config( {
    paths : {
        ModuleA : 'app/module.a'
    }
});
require( ['ModuleA'], function( moduleA ) {...});

src/main.js
----------------
src/app/module.a.js
src/main.js
 

As can be seen in the above examples, implementing a basic preprocessor is rather simple to accomplish with the RequireJS Optimizer. The ability to do so allows for some interesting possibilities and is certainly something worth checking out if you are leveraging AMD via RequireJS.

You can fork an example implementation at requirejs-preprocessor-example.

Handlebars, my preferred logic-less templating engine, simplifies testing even further via it’s elegant Helper API. While Handlebars may not be the fastest templating solution available, I have found it to be the most testable, reusable and thus, maintainable.

Custom Handlebars Helpers

Since Handlebars is a logic-less templating engine, the interpolation of values which require logical operations and/or computed values is facilitated via Helpers. This design is quite nice in that template logic can be tested in isolation from the context in which it is used; i.e. the templates themselves. In addition to the common built-in Block Helpers, custom Helpers can easily be registering in order to encapsulate the logic used by your templates.

Registering Custom Helpers

Registering Custom Helpers is as simple as invoking Handlebars.registerHelper; passing the string name of the helper which is to be registered, followed by a callback which defines the actual helpers implementation.

Consider the following custom Helper example, which, given a string of text, replaces plain-text URLs with anchor tags:

( function() 
{
	// define markup enhancement regex
	var protocol = /(\b(https?|ftp):\/\/[-A-Z0-9+&@#\/%?=~_|!:,.;]*[-A-Z0-9+&@#\/%=~_|])/gim,
	       scheme   = /(^|[^\/])(www\.[\S]+(\b|$))/gim;
			
	/*
	    * Registers a Helper method with Handlebars which, given a string of
	    * plain text or existing markup, provides enhancements of plain text 
	    * URLs, converting them to their respective anchor tag equivalents.
	    */
	Handlebars.registerHelper( 'enhance', function( text )
	{
		text = text.replace( protocol, '<a href="$1" target="_blank">$1</a>');
		text = text.replace( scheme,   '$1<a href="http://$2" target="_blank">$2</a>' );
		
		return new Handlebars.SafeString( text );
	});
}());
  

(Gist)

As can be seen in the above example, custom Handlebars Helpers are registered outside the context of the templates in which they are used. This allows us to test our custom Helpers quite easily.

Testing Custom Helpers

Generally, I prefer to abstract testing custom Helpers specifically, and test the actual templates which use the Helpers independently from the Helpers. This allows for greater portability as it promotes reuse in that common custom Helpers (and their associated tests) can then be used across multiple projects, regardless of the templates which use them. While one can test Handlebars implementation code with any testing framework, in this example I will be using Jasmine.

Essentially, testing Custom Helpers is much the same as testing any other method. The only point to be noted is that we first need to reference the helper from the Handlebars.helpers namespace. Ideally this could be avoided as, should the namespace happen to change, so, too, will our tests need to change. That being said, the probability of such a change is unlikely.

Using the above example, in a Jasmine spec, the enhance helper can be referenced as follows:

describe( 'Custom Handlebars Helpers', function()
{
	// define a reference to the underlying helpers namespace.
        // we can then access our helpers as methods and test them
        // as needed
	var helpers = Handlebars.helpers;
});
 

Then we can test that the helper was registered:

describe( 'Custom Handlebars Helpers', function()
{
	var helpers = Handlebars.helpers;
	
    describe( 'The "enhance" markup helper', function()
    {
        it ( 'should be registered', function()
        {
            expect( helpers.enhance ).toBeDefined();
        });
    })
});
 

We can then test any expectation. For example, the enhance helper should return a Handlebars.SafeString. We can test this as follows:

describe( 'Custom Handlebars Helpers', function()
{
	// define a reference to the underlying helpers object.
	var helpers = Handlebars.helpers;
	
    describe( 'The "enhance" markup helper', function()
    {
        it ( 'should be registered', function()
        {
            expect( helpers.enhance ).toBeDefined();
        });
        
        it ( 'should return a Handlebars.SafeString', function()
        {
            var isSafeString = helpers.enhance("") instanceof Handlebars.SafeString
            expect( isSafeString).toBeTruthy();
        });
    })
});
 

The enhance helper is expected to replace plain-text URLs with anchor tags. Before testing this, though, we should first test that it preserves existing markup. In order to test this use-case, we first need to access the return value from our custom Helper, we can do this by referencing the string property of the Handlebars.SafeString returned by our Helper:

describe( 'Custom Handlebars Helpers', function()
{
	// define a reference to the underlying helpers object.
	var helpers = Handlebars.helpers;
	
    describe( 'The "enhance" markup helper', function()
    {
        it ( 'should be registered', function()
        {
            expect( helpers.enhance ).toBeDefined();
        });
        
        it ( 'should return a Handlebars.SafeString', function()
        {
            var isSafeString = helpers.enhance("") instanceof Handlebars.SafeString
            expect( isSafeString).toBeTruthy();
        });
        
        it ( 'should preserve existing markup', function()
        {
            var expected = '<strong>Some unescaped markup</strong> and a <a href="#">link</a>';

            // We access the SafeString.string property to test 
            // our actual return value...
            var actual   = helpers.enhance( expected ).string;
        	
            expect( actual ).toEqual( expected );
        });
    })
});
 

Finally, we test that our enhance Helper replaces URLs with anchor tags using the above techniques:

describe( 'Custom Handlebars Helpers', function()
{
	// define a reference to the underlying helpers object.
	var helpers = Handlebars.helpers;
	
    describe( 'The "enhance" markup helper', function()
    {
        it ( 'should be registered', function()
        {
            expect( helpers.enhance ).toBeDefined();
        });
        
        it ( 'should return a Handlebars.SafeString', function()
        {
            var isSafeString = helpers.enhance("") instanceof Handlebars.SafeString
            expect( isSafeString).toBeTruthy();
        });
        
        it ( 'should preserve existing markup', function()
        {
            var expected = '<strong>Some unescaped markup</strong> and a <a href="#">link</a>';

            // We access the SafeString.string property to test 
            // our actual return value...
            var actual   = helpers.enhance( expected ).string;
        	
            expect( actual ).toEqual( expected );
        });
        
        it ( 'should replace URLs with anchor tags', function()
        {
            var expected = 'Check out <a href="http://handlebarsjs.com" target="_blank">http://handlebarsjs.com</a>'
                actual   = helpers.enhance( 'Check out http://handlebarsjs.com' );
        	
            expect( actual.string ).toEqual( expected );
        });
    })
});
 

(Gist)

We now have a complete test against our custom Helper, and all is green:

Note: The above Spec Runner is using the very nice jasmine.BootstrapReporter

And that’s all there is to it. You can fork the example at handlebars-helpers-jasmine.

After a brief search, I quickly came across jasmine-sinon which, to my surprise, provides a very similar matcher API to that which I had began implementing. This library really is quite nice as it essentially provides matchers for all common Sinon.JS spies, stubs and mocking use-cases. I am sure jasmine-sinon has saved many developers a lot of time by not having to write their own custom matchers as it has for me.

And so, if you are using both Jasmine and Sinon.JS, and find yourself writing convenience matchers to simplify Sinon.JS integration, jasmine-sinon is an excellent addition which compliments both and is certainly worth considering.

By default, Kendo UI provides out of the box templating support via Kendo UI Templates as well as support for jQuery Templates. While both solutions are quite good, I generally prefer logic-less Templating, with Handlebars being my preferred Template Engine of choice.

Fortunately, as it turns out, integration with Handlebars is actually quite simple. In fact, integration with basically any Template Engine is rather straight forward and can be implemented transparently.

Integration

In order to use a Template Engine which is not supported by default, one just needs to implement a Widget’s specific template property as a method which returns the resulting markup from a compiled template. This is easiest to understand by viewing examples in the context of both default templating as well as specific template integration.

First, templates in Kendo UI are typically implemented as follows (with this particular example being in the context of the rowTemplate of the Kendo UI Grid):

	
<script id="row-tpl" type="text/x-kendo-template">
    <tr>
        <td>${ name }</td>
        <td>${ released }</td>
    </tr>
</script>

<script>
    $( function() 
    {
        // Compile a typical Handlebars template...
        var template = Handlebars.compile( $( '#row-tpl' ).html() );
        	
		$( '#grid' ).kendoGrid (
		{
			dataSource: {
				data: [
					{ 'name': 'iPhone',     'released': 'June 29, 2007' },
					{ 'name': 'iPhone 3G',  'released': 'July 11, 2008' },
					{ 'name': 'iPhone 3GS', 'released': 'June 19, 2009' },
					{ 'name': 'iPhone 4',   'released': 'June 24, 2010' },
					{ 'name': 'iPhone 4S',  'released': 'October 14, 2011' }
				]
			},
         // Kendo UI Widgets directly assign a compiled template
         // to the Widget's template property (in this example, we're
         // using the kendoGrid widget's template property 'rowTemplate')
		    rowTemplate: kendo.template($("#row-tpl").html()),
		});
    });
</script>
  

Note that in the above example the compiled template is directly assigned to the rowTemplate property.

Now, to integrate a Template Engine of your choosing (in this example, Handlebars), assign a function to the rowTemplate property. The function assigned accepts a data object (which represents the data of a row) and, simply invoke the complied template with the data object, returning the result as follows:

<script id="row-tpl" type="text/x-handlebars-template">
    <tr>
        <td>{{name}}</td>
        <td>{{released}}</td>
    </tr>
</script>

<script>
    $( function() 
    {
        // Compile a typical Handlebars template...
		var template = Handlebars.compile( $( '#row-tpl' ).html() );

		$( '#grid' ).kendoGrid (
		{
			dataSource: {
				data: [
					{ 'name': 'iPhone',     'released': 'June 29, 2007' },
					{ 'name': 'iPhone 3G',  'released': 'July 11, 2008' },
					{ 'name': 'iPhone 3GS', 'released': 'June 19, 2009' },
					{ 'name': 'iPhone 4',   'released': 'June 24, 2010' },
					{ 'name': 'iPhone 4S',  'released': 'October 14, 2011' }
				]
			},
            // To integrate a specific Template Engine, simply have the
            // Widget's template property reference a function which in
            // turn returns the compiled template against the data argument.
			rowTemplate: function( data ) {
				return template( data );
			}
		});
	});
</script>
  

And thats all there is to it. You can try the above example implementation here.

As it turns out, it actually does; only there is a syntactical caveat to it – your immediate functions must have the closing parentheses defined outside of the function.

For example, while my preferred tool for validating Javascript is JSHint, the much stricter JSLint requires defining an immediate function’s invocation (i.e. the closing parentheses) within the function:

( function(){
}());
  

In JSLint, failing to do so, such as the following:

( function(){
})();
  

… results in the following error:

Error: Move the invocation into the parens that contain the function.

Being somewhat used to conforming to these (arguably unnecessary) rules, after some trial and error I found that adhering to JSLint’s requirements was in fact the cause of Aptana failing to provide an Outline View.

The solution to this problem is quite simple, just keep the invocation outside of the immediate function and Aptana will display the correct Outline View. Technically, I would consider this a bug on Aptana’s part and therefore have filed APSTUD-4364. Hopefully this issue will be resolved. In the interim, I hope this post helps.

Update: As of 04.05.2012, this has been fixed by the Aptana team. Details

In a previous post from a few months back I discussed some of the benefits of function overwriting in JavaScript. One similar performance optimization I regularly employee is that of One-time function initializations.

Conceptually, a One-time function initialization is a rather simple pattern which can be broadly described as follows:

1. An Immediate Function / Self-executing Function performs some initial test conditions.
2. The Immediate Function returns an anonymous function which, in turn, returns the results of the test conditions. Alternately, the Immediate Function can just return the test condition results.
3. The anonymous function returned is assigned to a function expression or, the test condition results are assigned directly.

An example in code illustrates just how simple this pattern is:

var hasSomeFeature = ( function() {
    // implement test logic... for example, testing
    // a feature's existence in the browser against
    // multiple vendor prefixes, etc.

    // return a function which returns the results, or
    // just return the result value if desired...
    return function(){
		// return results...
	};
}() );
  

Practical implementation example:

var hasWebSockets = ( function( window ) 
{
	var prefixes = 'ms O Moz Webkit'.split(' '),
	    n = prefixes.length,
	    i = 0;
	
	for ( ; i < n; ++i ) {
		if ( window[ prefixes[i] + 'WebSocket'] ) {
			return true;
		}
	}
	return 'WebSocket' in window;
}( this ) );
  

Implementing One-time function initializations are quite useful in many situations. Specifically, they are of most value when implemented for use-cases where conditions are too complex to assign to a variable directly and, when the conditions tested only need to be evaluated once, after which re-evaluating the condition would be redundant and unnecessary – such as certain feature detections.

As a general rule of thumb, if a condition or set of conditions can be tested once; that is, they are guaranteed to not change during the execution of the application and, the tests are too complex to maintain if directly assign to a variable, then implementing One-time function initializations are a small, yet simple and practical optimization.

Recently, I was contacted by a representative of the AT&T Developer Program informing me of the research conducted by the AT&T Research Labs and, the subsequent resources made available by AT&T as a result of their findings. Since I was unaware of this work, I was very interesting in learning more and, after reading the introductory statements, I was quite eager to apply AT&T’s recommendations as well; to quote specifically:

We quickly saw that a few, simple design approaches could significantly improve application responsiveness.

Having read through the material in it’s entirety (provided below) I must say I am rather impressed. The information provided has very real and practical implications on the design of Mobile Web Applications. Specifically, I found the clear and concise explanation of the underlying implementation of the Radio Resource Control (RRC) protocol to be particularly relevant and useful. RRC is by far one of the most important design factors to consider in terms of battery life and Application responsiveness and, as the research suggests, this may not have been common knowledge.

By far, the most interesting and notable aspect of the AT&T Research Lab’s work in this area is the fact that all of the information provided is applicable in the context of all Wireless Carriers, not just AT&T. That is, the recommendations given, such as those regarding the RRC State Machine, for example, are all based on carrier-independent standards and protocols implemented by all Wireless Carriers. As such, understanding the implementation specifics and recommendations provided is certain to prove valuable for all users of your Application, regardless of their Carrier.

If you haven’t all ready, I highly recommend reading and applying the principles provided by AT&T’s research to your current and future Mobile Web Application Designs.

AT&T Research Labs: Mobile Application Resources

Build Efficient Apps
Profiling Resource Usage for Mobile Applications: A Cross-layer Approach

Luckily, with Charles, on iOS this is quite simple to accomplish.

Configuration

To configure Charles to proxy all requests from an iOS device, simply follow these basic steps:

1. From your iOS Device, open Settings.
2. Go to Wi-Fi, select your Network and select the Blue “arrow” icon.
3. Scroll to HTTP Proxy and select the Manual Button.
4. In the Server field, enter the IP address of your development machine.
5. In the port field, enter port 8888 (the default port to which Charles binds).
6. Leave Authentication set to Off.

And that’s all there is to it. Now, open Mobile Safari and go to your Web Application’s URL (or any page on the web for that matter). On your development machine, in Charles you will receive a prompt with the IP Address of your Mobile Device, click “Allow” and you are all set. When you are done working, make sure to turn off HTTP Proxy on your device.

Additional Note

While this article may be focused on Mobile Web Applications, these same configurations apply to all HTTP traffic from any application on your device that requires resources over the web.

While jQote2 provides a perfect API for templating, it does not provide a method specifically for loading external templates; this is likely due to the fact that loading external templates could easily be accomplished natively in jQuery. However, since this is a rather common development use case, having such a facility available would be quite useful.

After reviewing the comments I came across a nice example from aefxx (the author of jQote2) which demonstrated a typical approach to loading external templates which was simular to what I had been implementing myself.

And so, I wrote a simple jQuery Plug-in which provides a tested, reusable solution for loading external templates. After having leveraged the Plugin on quite a few different projects, I decided to open source it as others may find it useful as well.

Using the Plugin

Using the jQote2 Template Loader plugin is rather straight forward. Simply include jQuery, jQote2 and the jquery.jqote2.loader-min.js script on your page.

As a basic example, assume a file named example.tpl exists, which contains the following template definition:

<script type="text/html" id="articles_tpl">
	<![CDATA[
    	<% var article, i, n;
    	   
    	   for ( i = 0, n = this.articles.length; i < n; i++ ) {
			     article = this.articles[i]; 
		 %>
			<article>
				<header>
					<h1><%= article.name %></h1>
				</header>
				<p><%= article.text %></p>
			</article>
        <% } %>
	]]>
</script>
  

We can load the example.tpl template file described above via $.jqoteload as follows:

$.jqoteload( 'example.tpl', function( templates )
{
	// create some mock articles...
	var articles = [ { name: 'Article A', text: 'Articles A test...'},
					 { name: 'Article B', text: 'Articles B test...'},
					 { name: 'Article C', text: 'Articles C test...'} ];
    // Render the articles...
    $('#articles').jqoteapp( templates.articles_tpl, { 'articles': articles } );
});
  

After example.tpl has been loaded, from another context we can access the compiled templates via their template element id. In this example "articles_tpl".

//... within some other context, access the same compiled template
var template = $.jqoteret( 'articles_tpl' );
  

You can grab the source and view the example over on the jQote2 Template Loader Github page.

Being that I was unfamiliar with DHTMLX Touch (as I have been using jQuery Mobile almost exclusively), I was quite interested to learn more; and, having tried the Examples and reviewed the Documentation, I was rather impressed by DHTMLX Touch.

And so, if you haven’t already, check it out.