configurable widget

asconfigurable.js

// this would live in auxl
define([
    'vendor/jquery',
    'configuration'
], function($, configuration) {
    return function(options) {
        var name = options.name;
        this.configuration =
            $.extend(true, this.configuration, configuration[name]);
    };
});

configuration.js

// this would be generated server-side similar to the 'strings' module,
// there wouldn't actually be a configuration.js file
define([], function(){
    return {
        viewwithfourslots: {/*...*/}
    }
})

viewwithfourslots.js

define([
    'vendor/underscore',
    'gloss/view',
    'auxl/asconfigurable',
    'module'
], function(_, View, asConfigurable, module) {
    var ViewWithFourSlots = View.extend({
        defaults: {/*...*/},

        configuration: {
            // this is where the defaults go
        },

        init: function() {
            /* ... */
        }
    });

    asConfigurable.call(ViewWithFourSlots.prototype, {
        name: _.last(module.id.split('/'))
    });

    return ViewWithFourSlots;
});

this would work for a bare-bones implementation of the configurable ui element. a few things to note:

• we're determining the name of the configurable widget using the require.js 'magic module', so in this case it'll be viewwithfourslots (regardless of what we name that var in the file)
• it'd be nice to update configurable.js such that this.configuration is a class that's been mixed-in w/ assettable.js, enabling stuff like this.configuration.get('foo.bar')
• if you inherit from View, then accessing the configuration from w/in the view's template is as easy as this.configuration

this of course doesnt address anything about how we get the configuration down to the client. that'd involve a context processor, and it would be strait-forward enough to just mimic the approach we're taking w/ string bundles.

updated w/ a note about setting default options.