|
One of the areas of complexity while building Fluid components is getting at elements in the DOM flexibly and unobtrusively.
The DOM Binder is, at this stage, a conceptual API designed to relieve the component developer from some of the burden of handling this complexity.
Every component has a dom() function, used to access things in the DOM. It always returns a jQuery. Interesting things are referred to only by name in the component code, not via the specific means of fetching.
var showProgressBar = function() { dom.progressBar().show(); }; var highlightTheThirdFileRow = function () { dom.fileRows().eq(2).addClass(styles.highlight); }; |
Initialization of a DOM binder is two-line affair:
// interestingThings is a set of "things" (DOM elements) that the component is interested in working with. // A component defines a default set of these, but the user can override them as desired to allow for radical variations in markup. fluid.myComponent = function (containerId, interestingThings) { // fluid.view instantiates a new view object with the dom automatically bound for us. // Behind the scenes, the dom binder merges defaults with the user's overrides and finds things in the dom, // safely constrained to a particular container. var that = fluid.view(container, defaults.things, interesting things); // Do interesting stuff with your things. var rowStriper = function () { that.dom.fileRows().find(":even").addClass(styles.stripe); }; var bindSave = function () { that.dom.saveButton().click(function () { alert("Hello DOM binder!"); }); }; // Make sure you provide good defaults for finding interesting things, so that users don't have to specify them unless they need to. var defaults = { things: { fileRows: ".fileRows tr", saveButton: ".save" } } }; |
The Reorderer evolved quickly while we learned how to program JavaScript. It has some tight coupling that could be improved by pulling out nameable, discrete units of functionality. Here's a diagram traced directly from a whiteboarding session:
This is one of the ugliest diagrams I've ever produced, and it can be confusing because it traces method calls, containment relationships, and inheritance in a single shot. Remember, it's just a sketch!
Pager's architecture sketch, based on analysing the wireframes and story cards, looks a little something like this:
We're in the midst of revisiting the Uploader architecture to simplify its structure. Our goal is to break Uploader up into separate units, each concerned with a discrete piece of UI functionality. Ultimately, much of the new architecture represents a series of View objects that work on an underlying Model representing a collection of files. This is still very much a sketch.
First pass at designing the UI Options functionality.