dylans
commented
7 years ago One of the not yet done things for widget-core is the concept of a scene manager, which I think could help dgrid a lot in managing the thinking around this perhaps (or at least be conceptually similar).
Editing basically takes data and replaces it with an editor that then acts on the data. The dgrid 1 approach somewhat mixes the concept of properties and events/changes. For example, editor and editorArgs are child widget configuration, editOn and canEdit configure change handlers to toggle between data and a child widget, autoSave and autoSelect configure enabling various change handlers for the underlying data and selection events, and dismissOnEnter is configuration for a child widget change handler. rowEdit (or whatever it should be called) is similar to editOn, except that it acts upon a group of child widgets rather than a single cell/widget.
I cannot think of a better place than a column definition, though perhaps there's a better way to generalize this so the column definition doesn't become difficult to work with. As noted, perhaps a scene manager or more semantics around state management would help?
For item properties, given that we're perhaps thinking of each cell as a widget (which is easier to do in a Dojo 2 world), then perhaps that makes it more generalized. The question for me becomes, is a cell with various editing capabilities a cell widget that then may add a child widget, and how does the cell manage the relationship with various types of child widgets? We should also assume a cell could contain any arbitrary widget, not just a form field. For example, suppose someone wants to include a sparkline chart or a progress bar.
For widget definition, I'd hope we have some consistent way for a parent widget to pass configuration and settings to child widgets that we could reuse here, rather than dgrid having a one-off approach.
I don't have any useful comments at this time about Data Providers.
cc @agubler and @matt-gadd for their thoughts.
Enhancement
In dgrid 1, the following attributes are added to a column definition in support of editing:
It's been noted that one thing frequently considered for dgrid 1 was to also allow an edit on row click (https://github.com/SitePen/dgrid/issues/1092) rather than just cell click.
Does this Belong in a Column Definition?
During the design of dgrid 2, it's been a priority to limit columns to properties relevant to bridging the gap between the underlying data and the grid. Many of the properties added to a column are closely associated with the data itself.
One obvious problem is when we have interdependent widgets within the same row. A checkbox may appear in one item that may change the type of input another column accepts. The only way to do this in dgrid 1 was to manage this behavior manually by tracking the created widget instances and manually adding events. Finding a way to avoid this in dgrid 2 would be a good idea.
Another problem is when a different type of widgets or a widget with different properties needs to be used depending on the properties of the data object itself.
Item Properties
We've already introduced configuration options for each item in the grid - things like whether it can be/is expanded. By extending this pattern, we can once again put a significant amount of onus on the data provider and remove some of the brittle interactions we introduce by managing everything within the grid.
This would fix the problem outlined above where in dgrid 1, you could edit on cell click but not row click. Instead, the data provider could listen for a row to be clicked then customize each cell in that row with editing functionality. While much of the functionality can be performed by the data provider, we should still have dgrid manage the interactions with the widgets themselves.
Widget Definition
Do we feel that using editor/editorArgs is the way we'd want to customize what type of editor widget we'd create? If we figure out how cell widget content should be defined in general, that pattern may be used but with something like
editor: truein Item Properties to note the difference.Data Provider
By default, data providers can allow configuration on a column-by-column basis. Data providers could then be extended when necessary so that this configuration could be tweaked based on the item data. We should consider this pattern as part of our data providers - where a method is called with the item data and the item properties generated by the data provider and allow the method to alter the item properties before being passed to the grid.
When modifying and saving data - because the data provider is the only code that knows about the underlying data - it will need to responsible for managing changes to the data.