Refactor the data methods of Create objects out of the jQuery UI presentation layer

[jessebeach]

Presently, Create objects mix state and data controlling code like the method setState with presentation code like

if (widgetName) {
  // only if there has been an editing widget registered
  jQuery(data.element)[widgetName](data);
  jQuery(data.element).removeClass('ui-state-disabled');

  if (data.element.is(':focus')) {
    data.element.blur();
  }
}

I think we can maintain the defaults that produce the basic UI elements like the toolbar while also exposing just the core data methods to developers who want to implement their own UI and deal with user interactions.

What I'm proposing is that we shift the data methods into an API object that gets passed into the jQuery wrapper to preserve backwards compatibility and the path to the basic UI. The API object is made available through a global namespace object. Here's the basic structure.

(function ($, undefined) {

  'use strict';

  var defaults = {};

  var api = function (options) {
    return { /* Data/state methods */};
  };

  // Define Create's EditableEntity widget.
  $.widget('Midgard.midgardEditable', $.extend(true, (new api()), { /* Presentation methods */}));

  // Expose the API as basic object.
  window.Midgard = window.Midgard || {};
  window.Midgard.midgardEditable = api;

}(jQuery));

[wimleers]

@bergie: should this use window.Midgard, or should this rather use window.Create, which matches the project name?