Patch for FLUID-839: multiple inline edits

[Colin Clark]

Hey,

On the train to Paris I made some improvements to the Inline Edit  
component. Currently, you have to instantiate all the inline edit  
fields on a page one at a time.

To make this simpler, I created a new method, fluid.inlineEdits() that  
will fire off a whole set of inline edit fields in one shot. I'd like  
to take advantage of this new API for several examples at the  
conference.

Here's the JIRA ticket with a patch:
http://issues.fluidproject.org/browse/FLUID-839

This is a bigger patch than I'd normally create, but I did some  
cleanup and refactoring along the way. Aside from inlineEdits(),  
here's a summary of the other changes in this patch:

1. I added a new top-level convenience function, fluid.container().  
Tests are included. fluid.container() is designed to enforce the  
contract a fundamental contract for components: we expect a single,  
unique container for each component. It accepts several different  
types of objects (a selector, a jQuery instance, or an Element), and  
will return a jQuery instance. It throws an exception if exactly one  
container element is not found. fluid.container() will be part of the  
new DOM Binder API which I will finish soon.

2. I refactored the InlineEdit() constructor function to be a bit  
smaller and more modular. This will also help when we port it to our  
new simpler structure for components. I'll send another email soon  
about hte new component structure, but in the meantime you can see a  
sketch of the plan in the "that-ism: section of my Architecture  
Sketches wiki page:

http://wiki.fluidproject.org/display/fluid/Architecture+Sketches

3. I ported the Announcements example markup to use inlineEdits()  
instead of instantiating each inline editor individually.

Can you take a look at it and let me know if you think this a  
reasonable approach?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org