API changes in 1.3: Inline Edit

Lam, Mike mlam at ocad.ca
Thu Nov 4 14:42:57 UTC 2010

These are the following functions moved into the public namespace:

fluid.inlineEdit.setupEditField = function (editStyle, editField)
fluid.inlineEdit.setupEditContainer = function (displayContainer, editField, editContainer)
fluid.inlineEdit.defaultEditModeRenderer = function (that) 
fluid.inlineEdit.renderEditContainer = function (that, really)
fluid.inlineEdit.setupInstructionText = function (instructionTextStyle, instructionText)
fluid.inlineEdit.positionInstructionText = function (instructionText, editContainer, editField)
fluid.inlineEdit.setupDisplayModeContainer = function (styles, displayModeWrapper)
fluid.inlineEdit.setupDisplayView = function (that)
fluid.inlineEdit.setupTextEditButton = function (that)
fluid.inlineEdit.updateEditButtonAltText = function (textEditButtonImage, model, strings)
fluid.inlineEdit.bindHoverHandlers = function (displayModeRenderer, invitationStyle)
fluid.inlineEdit.bindHighlightHandler = function (element, displayModeRenderer, styles)
fluid.inlineEdit.bindMouseHandlers = function (element, edit)
fluid.inlineEdit.bindKeyboardHandlers = function (element, edit)
fluid.inlineEdit.makeEditTriggerGuard = function (element, edit)
fluid.inlineEdit.defaultDisplayModeRenderer = function (that)

I don't think the following functions should be in the public namespace:

fluid.inlineEdit.makeEditTriggerGuard = function (element, edit)
fluid.inlineEdit.bindMouseHandlers = function (element, edit) 
fluid.inlineEdit.bindKeyboardHandlers = function (element, edit)

The above are generic functions to toggle between the display and edit modes.  These function signatures take a generic html element that get keyboard and mouse events attached to them.   I believe it's the core of the component and I wouldn't want an integrator to change the functionality of this.

Perhaps we could also remove the other binding functions from the public namespace by refactoring the function signatures to take in an array of styles which would give the user to have more control over the number of styles added to these events.   

The remaining functions could stay public as they create default HTML markup for the component and we would want the user to have the option to change the markup.


From: Justin Obara [obara.justin at gmail.com]
Sent: November 4, 2010 9:47 AM
To: Colin Clark
Cc: Lam, Mike; Cheetham, Anastasia; Fluid Work
Subject: Re: API changes in 1.3: Inline Edit

In regards to the new public functions, I believe that most if not all of them are used as part of the render functions. This is to allow users who want to create their own render functions to not have to rewrite everything from scratch.

I don't think we added any comments to those functions though, and we should go back and do this.

- Justin
On 2010-11-04, at 6:41 AM, Colin Clark wrote:

> Can you enumerate the various functions you've moved into the public namespace, and elaborate on why you think they're "things that aren't actually meant for public use?" I'd encourage us to either stretch our assumptions about what might be fit for public usage, or--if these functions really aren't suitable for anyone to use--remove them from public view. The former is, of course, preferred.

More information about the fluid-work mailing list