cujo-ish view/widget

_MyView.js

// It'd be great to get rid of this file entirely!

//MyView.js (filename above is just to sort this to top)
define([
	'wire!./myView/spec',
	'poly!poly/array' // for instance, not used in this example
],
function (spec) {
	return spec;
});

app-spec.js

define({
	plugins: [
		{ module: 'cujo' }
	],
	myView: {
		// Create an instance of myView?
		// Not sure yet how we'd create multiple instances, Object.create?
		'cujo.view': 'path/to/myView'
	}
});

controller.js

// myView/controller.js
define({
	// At this point, this is pretty much a "javascript-less" view!

	// _onClick: function (e) {
	// 	this.rootNode.classList.toggle(this.states.selected);
	// }
});

spec.js

define({
	template: { module: 'text!./myView/template' },
	strings: { module: 'i18n!./myView/strings' },
	// Since, in this example the result of onClick is a state change,
	// maybe we could shorten it via cola, or another facet that lets us
	// define a state machine in the spec?
	states: {
		unselected: {
			// When we're in the unselected state, and rootNode:click fires,
			// transition to selected
			// Here, selected could be a robo state, that may, in this
			// case, simply cause an OOCSS state change.  But you could
			// imagine it doing other things, too!
			'rootNode:click': 'selected'
		},
		selected: {
			// Contrived example ... clicked while in the selected state
			// causes a transition back to unselected
			'rootNode:click': 'unselected'
		}
	}
});

strings.js

// myView/strings.js
define({
	greeting: 'Hello, cujo-er!'
});

template.html

<!- myView/template.html -->
<div class="myview" data-cujo-bind="rootNode"><!-- should rootNode be implicit? -->
	<p>${strings.greeting}</p>
	<p data-cujo-bind="foo"></p>
</div>

ZZZ_MyView.js

// MyView.js when concatenated together using cram.js
// cram.js needs two new features to make this work:
//     1. an option to NOT normalize module ids
//     2. an option to more easily exclude modules from the build (wire plugins, for instance)

define('./myView/controller', {
	_onClick: function (e) {
		this.rootNode.classList.toggle(this.states.selected);
	}
});

define('text!.myView/template.html', function () {
	return '<div class="myview" data-cujo-bind="rootNode"><!-- should rootNode be implicit? -->\n\t<p>${strings.greeting}</p>\n\t<p data-cujo-bind="foo"></p>\n</div>';
});

define('i18n!./myView/strings', {
	greeting: 'Hello, cujo-er!'
});

define('wire!./myView/spec', {
	plugins: [
		{ module: 'wire/dom' },
		{ module: 'wire/html5Event' } // adds `on` facet plus html5's node.classList!
	],
	oocssStates: {
		selected: 'selected'
	},
	controller: { 
		module: './myView/controller',
		on: {
			rootNode: 'click:_onClick'
		},
		properties: {
			states: { $ref: 'oocssStates' }
		}
	},
	template: { module: 'text!./myView/template' },
	strings: { module: 'i18n!./myView/strings' }
});

define(/* yes, this should stay anonymous! */ [
	'wire!./myView/spec',
	'poly!poly/array' // for instance, not used in this example
],
function (spec) {
	return spec;
});

Yeah, good points. I think there could be confusion about MyView.js vs. controller.js ... i.e. "Where does my code go?!?". I think we'd need to make sure there's a clear place for everything. That's what I was shooting for: having controller be the place where your code goes, since MyView.js is really just a boot file for the widget.

Is there any way to use the file that loads/wires the spec to also hold the event handlers?