This example demonstrates the inline editing capabilities of Flexicious Ultimate. Most of the external API works similar to the Adobe implementation, however, internally it is slightly different. We did this to make the editing process very customizable, and give you the ability to hook into the process with ease.
First, let’s quickly review the source:
You will notice the familiar editable=true flag, which simply displays a textbox and populates it with the value of the datafield of the column being edited. When the value in this textbox is committed, the grid will apply the value back to the dataprovider.
Then there is the itemEditor and the editorDataField properties, that let you specify custom item editors. For example, the last date column, for the itemEditor, we specify a ClassFactory that takes a DateField. For the editorDataField, we specify selectedDate. This means, we want the editor’s selectedDate property to set to the dataField of the row data on editor initialize, and vice the versa on editor value commit.
Finally, a few special properties that we provide that make the overall edit process easy to customize:
1) enableDoubleClickEdit: Flag to enable edit on doubleclick as opposed to single click. Editable columns begin edit when the user clicks on their cells. In cases where you have a cell based selection mode, this conflicts with the user gesture of selecting a cell. In scenarios like this, you may wish to set enableDoubleClickEdit=true
2) itemEditorManagesPersistence: Indicates that the item editors manage their own persistence and populating the dataprovider back with their changes, so the editorDataField is ignored and the DataGrid does not write back the value from the editor into the data provider.
3) itemEditorValidatorFunction: Function to call before committing the value of the item editor to the data provider. Should take a UIComponent with is the item editor, and return a true or a false. If false, value is not committed If true, value is committed.
A quick overview of the editing functionality:
1) When the user clicks on a cell that is editable, or double clicks when enableDoubleClickEdit is set to true, the beginEdit function is called on the Body Container. The Begin Edit ends the current edit , if there is one, and dispatches the ITEM_EDIT_BEGINNING event. If you prevent default on this event, the editing ends. Next, it creates an instance of the itemEditor class factory (defaults to Text Input), sets the value of the editorDataField (defaults to text), and positions it in place, and sets focus into it. Once this is done, it calls the dispatches the ITEM_EDIT_BEGIN event.
2) When the user presses a key:
a. On Escape, we call the cancelEdit function.
b. On Enter or Tab: We call the populateValue function.
i. If Enter, we move on to the same column in the next row if the next row is of the same nest depth. Else, we move to the nearest editable cell on the row. If tab, we move to the next cell in the same row, if the current cell is not the last. Else we move to the next row, first editable cell.
c. On any other key : The editor responds to this key.
3) The populateValue function:
a. Checks to see if itemEditorManagesPersistence is true. If yes, then we do nothing else
b. Dispatches the ITEM_EDIT_VALUE_COMMIT event. If the default is prevented on this method, we do nothing, otherwise, we check to see if there is a itemEditorValidatorFunction, and if it returns true or it is null, we apply the value of the editorDataField property of the editor to the dataField property of the rowData of the cell. If itemEditorValidatorFunction returns false, or if the default is prevented on the ITEM_EDIT_VALUE_COMMIT, we do not call endEdit. Else, we do.
c. We refresh the cell.
4) The cancelEdit function:
a. Dispatches the ITEM_EDIT_CANCEL event. If the default is prevented on this, does nothing, else calls endEdit.
5) Refreshes the cells The endEdit function:
a. Destroys the current editor,
b. Dispatches the ITEM_EDIT_END event.
c. Refreshes the cells