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?
The value of View for DataTable is in providing an API contract. By default, DataTable's views render things a certain way. By subclassing one of DataTable's views and customizing it, a user can easily swap out the default behavior for a view that uses Handlebars for rendering, or that defines custom interactions, or any number of other things. A user could even use one set of views to render DataTables on the client, and another set of Views (but the same underlying DataTable code) to render them on the server. Or one set on desktop, another on mobile. And as users begin to write View extensions and plugins, DataTable's views will benefit from them.
The fact that DataTable doesn't use much of View's API doesn't seem relevant (especially given that View doesn't have much of an API); what's relevant is that by using Views, DataTable is opening up a world of extensibility possibilities that would otherwise be more difficult to achieve.