These are my early thoughts on how to structure DataTable in 3.5.0. Feedback is welcome in the comments.
new Y.DataTable({...});
new Y.DataTable.Base({...});
Y.DataTable.Base = Y.Base.create('datatable', Y.Widget, [Y.DataTable.Core]);
Y.DataTable = Y.mix(
Y.Base.create('datatable', Y.DataTable.Base, []),
Y.DataTable, true);
Class extensions CAN (if non-invasive by default)
Y.Base.mix(Y.DataTable, [ Y.DataTable.Sortable ]);
new Y.DataTable({
data: [{ ... }, { ... }, ... ]
data: modelList
data: {
source: url, function, xml
type: 'json'
schema: { ... }
}
columns: (optional) [ key, key, { key: key, config: stuff, ... }, ... ]
recordType: (optional) ModelClass
headerView: (optional) ViewClass
bodyView: (optional) ViewClass
footerView: (optional) ViewClass
summary: (optional) 'string'
caption: (optional) 'string'
});
instance
.data = modelListInstance
.head = viewInstance
.body = viewInstance
.foot = viewInstance
-
Y.DataTable.Core
Everything added to Y.Widget to make DataTable.Base
-
Y.DataTable.HeaderView
-
Y.DataTable.BodyView
-
Y.DataTable.FooterView
Used by DataTable(.Base) to render the table contents.
Referenced via configuration, not composition.
-
Y.DataTable.Source
Optional class extension.
Adds support
data
config to generate ML with DataSource load. -
Y.DataTable.Scrollable
Optional class extension.
Adds support for scrolling table. May be used to create a third instantiable class.
-
Y.DataTable.ScrollingBodyView
Used in place of DataTable.BodyView to render the scrolling table. May not be necessary?
-
Y.DataTable.Sortable
Adds support for sorting headers and sortable config.
instance.render(...)
- build <table> (markup only or off DOM node?)
- instantiate header, body, footer views passing
- the DT instance
- the created table?
- the
data
ModelList?
- call each view's render()
Logic for reacting to user input is moved to the View classes
Concern: string based rendering would have viewX.render() return a string or populate a property, but it has requirements of the DT renderer
instance.load(...)
Pass through to this.data.load(...). Let the ModelList be responsible for data interaction.
- No ModelList is provided in
data
configuration AND - No
recordType
is provided in configuration
- Use the first item in the data array to build ATTRS and Y.Base.create(...)
- If data is empty, use columns?
Again, the value of View for DataTable is less about what DataTable can get from it and more about what DataTable's users can get from it. Even so, I'm curious why you don't find View's event delegation valuable. Seems perfect for DataTable.
Regarding the Node creation requirement: there isn't one. View's
create()
method creates a Node by default, but it's intended to be easily overridden if you want it to do something else. Ditto theattachEvents()
method. Also,create()
isn't called by View'sinitializer()
method, it's called because it's the setter for thecontainer
attribute. You can easily override the attribute config without having to override the entire initializer.