I’m putting together a kind of JavaScript TableModel object to facilitate some things on a project at work. So, this is my cram session for it. You can see the ideas change and clarify as it goes.
TableModel is the data.
TableView binds to and inspects the TableModel to determine how/what to display
BeanBackedTableModel has a data object that serves as the backing for the actual cell data in the table.
However, TableModel is PRIMARILY the model for the actual TABLE. So, it holds the state for the TABLE entity. The fact that part of that state may come from an underlying data object is secondary.
TableView must be able to (potentially given the type of TableModel) reconstruct the model only from the (potentially very basic) view representation. So, for example, on an initial page load if there is data in the table by default, that data should be extracted/scraped from the view to initialize/construct the inital model. This feature may also be implemented as an entirely separate object…a TableModelInitializer perhaps.
In the latter case, the TableView that eventually is bound to the same table must be made aware of the inital state (this is why it may make sense for the 2 things to be on the same object.
So, ‘what state does a table have’:
columns
rows
header
footer
caption
summary
(future) support RTL directionality
Stab at a Requirements List:
1. Table Structure CAN still be defined by the markup.
2. Table Sturcture CAN be entirely JS-built
3. JS Table Model can be reconstructed from the markup.
4. JS Table Model (data) can be backed by a JS Domain Object or collection of them.
5. Can add Domain objects directly to the table.
6. Can edit (optionally) the table model (data) directly in the table.
7. Can sort the table model (data).
8. Developper can take an existing static table and easily behavior-ify it (add sortability and even in-line updating) in a declarative fashion.
9. Can handle/do paging
10. Can do static header/scrollable data section.
11. Can break columns into sections.
12. Can have static columns.
13. Support a kind of extension model. new features can be attached to the table model (like drag-n-drop column arrangement, show/hide columns, etc).
14. Completely/easily css styled.
15. Data Model should be easily extracted from table (for ajax update/insert
purposes). Consider ability to distinguish/notify of: rowupdated, deleted, added.
16. Ability to select/deselect rows (be careful with pager integration as well as pager integration with the sort capability). Does this imply a difference between the full data model and the displayed dom model? The pager very much just controls what rows are displayed…it could be made aware of changes to the actual underlying data model. Would sort-order actually modify the data model? or would that too merely be a display thing. So the actualy model is always in initial and insertion order…then the sort ‘module/extension’ keeps the actual sorted model (or index) off to one side and modifies the actual dom as sort requests come in. Well, we have 2 models really…the actual TableModel and the DataModel that backs it. The DataModel could be always kept in insertion order, and the TableModel (SortableTableModel?) could be aware of the order and return the rows in the appropriate order. Then have a nother model for the pager (PageableTableModel?) for the page-ability. Then the models would have to be stackable (decoratable). So you could have a sortable table model that is wrapped by a pagabletablemodel. the getRows function would first be processed by the sortable and it would return the rows in sorted order then the pager would break it up (post-sort) and page accordingly. The select-all feature would have to get the list of rows from the table model and then select all of the ones returned. I suppose some caching could take place or some other optimization (for example, the model could have some sort of modified event that could fire and the wrapping instance could listen for that event and invalidate its current state (or what was returned by the wrapped model). otherwise assume the rows are the same (at least according to the wrapped instance) and the old ones can still be trusted and returned.
So, for a base TableModel we need what?
1. getRows
2. getColumns
3. getDataModel
4. getHeader (allows changes in th and others…for things like dnd columns).
5. getFooter
The Rows are an array of the actual TR objects that should appear in the data (tbody) section(s) of the table. (for now only one tbody section is supported…should be able to refactor later to support getRowGroups and getColGroups instead…).
DataModel always holds all of the data for the table (even data for cols and rows not displayed) in insertion order. It will always be an array. The array may contain: arrays, hashes, or objects. The default data model will simply be a 2d array of strings. When modifying a table (adding/removing rows) the DataModel is what is manipulated. When modified it will fire a modified event…the table model will be nofitied of it and will modify its rows collection and fire a modified event of its own with the new DOMRow as a property on the event (which will travel up the chain to the JSTable object, potentially being further modified/behavior-ified along the way). The JSTable will then decide it is time to update the view (depending on the type of event (added/removed/updated) and will affect the change to the underlying dom table.
Ok…good for an up-front design/cram session. Now go do some TFD keeping this in mind as something to work toward.
