Patch for FLUID-839: multiple inline edits

[Colin Clark]

Anastasia,

Thanks for taking a look at the patch...

Quoting Anastasia Cheetham <a.cheetham at utoronto.ca>:
> You use fluid.defaults() to define defaults for "inlineEdits"
> The InlineEdit component still has separate defaults defined on the
> prototype, a practice we're moving away from.
> Is it the intention that we eventually move the current prototype
> defaults in with the ones you assigned to "inlineEdits"?
> Or are the defaults for "inlineEdits" different than the defaults for
> "InlineEdit"?

We'll be moving away from the use of prototypes in order to simplify  
our component structure. I'm hoping to get some time to port Inline  
Edit to this new style sometime during the conference, but in the  
meantime we'll maintain both styles to keep the tests passing. One  
step at a time. The Tabs example, part of the Fearless JavaScript  
workshop, outlines the new style.

The defaults for inlineEdits are different than those for a single  
Inline Edit component. These defaults store selectors specific to the  
creation of a *set* of inline edits.

> I guess the real question has to do with the intended use of
> fluid.defaults() (and forgive me if this was already discussed - if so,
> I missed the discussion (I couldn't find anything on the list or on
> IRC)):

I haven't yet had a chance to document my thinking on this topic, so I  
apologize if it's still a bit fuzzy. The creation of fluid.defaults()  
was the product of discussions with Antranig and Michelle over the  
past week or so, as part of our move to using plain old JavaScript  
objects and functions.

> Is the intended general practice going to be that we create a single
> set of defaults for each component?
> Or that we use the centrally stored defaults to store as many small
> chunks of defaults as we feel is appropriate (e.g. a set for the main
> constructor, another set for the inlineEdits() function, maybe another
> set for other yet-to-be-defined convenience functions, etc)?

I'm open to suggestions for how to handle this. In my mind, the  
fluid.defaults() is a central registry for the default settings for  
components. The decision on how defaults should be organized is based  
on ensuring a separation of concerns. In this particular example,  
InlineEdit represents a single instance of the component, while  
inlineEdits() is a set of them. Hence separate defaults.

Thoughts?

Colin

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