Patch for FLUID-839: multiple inline edits

[Anastasia Cheetham]

On 27-Jun-08, at 1:16 PM, Colin Clark wrote:

> On the train to Paris I made some improvements to the Inline Edit  
> component.... I created a new method, fluid.inlineEdits() ...
> Here's the JIRA ticket with a patch:
> http://issues.fluidproject.org/browse/FLUID-839
>
> Can you take a look at it and let me know if you think this a  
> reasonable approach?


I've commented on the ticket itself, but for people not monitoring  
that issue, here are the comments:

Colin, some questions about your patch:
Actually, I guess they're questions about the intention for the  
centrally stored component defaults, now that I see them applied in a  
real context:

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"?

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)):

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)?

Other than my questions about defaults, the patch looks good - a very  
nice improvement.

-- 
Anastasia Cheetham                   a.cheetham at utoronto.ca
Software Designer, Fluid Project    http://fluidproject.org
Adaptive Technology Resource Centre / University of Toronto