create.js

/*

If we break up _create() as shown below, we get an extension-friendly, enhanced-aware,
reflow-minimizing startup process.

_establishStructure():

	Action in the traditional case:
		Creates elements and establishes parent/child relationships between them. It may detach
		this.element from the DOM.

	Action in the pre-rendered case:
		Retrieves elements from the DOM and does not detach anything.

	In both cases, the resulting elements are stored in instance-level variables.

_setAttributes():
	This function is enhanced-option unaware. It calls _addClass() and .attr() on instance-level
	variables established in _establishStructure().

	By the time _setAttributes() is called, it is guaranteed that all instance-level variables have
	been initialized either with new DOM elements or with elements retrieved from the DOM via
	selectors.

	The effect in the traditional case:
		Reflows are avoided because, although the new DOM elements have been created, they are not
		attached to the DOM yet when class and other attributes are being set.

	The effect in the pre-rendered case:
		Reflows are avoided because, although the elements are already attached to the DOM, the
		attributes (including class) are being set to values they already have.

_attachToDOM():

	Traditional:
		Elements created in _establishStructure() and decorated in _setAttributes() are attached to
		the DOM.

	Pre-rendered:
		Nothing happens.

_addHandlers():
	This function is enhanced-option unaware. Attach event handlers.

Extensions need only implement these functions, rather than _create(), but if pure calculations
are to be done, they can go into _create(). For example, if you need to determine how many new DOM
nodes you need to create, you can do so in _create() before any of these functions run.
*/

_create: function() {

	// calculations

	this._establishStructure();

	// Includes adding classes, because class is also a DOM attribute
	this._setAttributes();

	this._attachToDOM();

	this._addHandlers();
}

... or, more succinctly:

this
    ._establishStructure()
    ._setAttributes()
    ._attachToDOM()
    ._addHandlers();

Even if we ultimately do not adopt this sequence of extension point calls, I think it's a good way of thinking about a widget with multiple extensions. If you write the widget and its extensions in this way at first, and then (optionally, and only if separable) reduce back to _create() + _enhance(), you get an init sequence that's as reflow-free as possible.

Unless this gets shot down by a well-placed point I've missed I, for one, will definitely be taking this approach when doing the jQM table, which, as of the review, has at least three extensions.