Forums

I'm talking about YUI3 in terms of YUI2 simply because YUI2 is what I know, and this is something I would have liked to have in YUI2 so I'm wishing for it in YUI3.

Data manipulation in the DataTable has four possible transformations. With the main repository for the DataTable being the Recordset, it has one transformation each way to and from the server and to and from the screen.

The transformation from the server to the Recordset is currently (YUI2) handled by the DataSource by specifying the parser in the fields array. There is no place to specify the return transformation, from the Recordset to the server.

The transformation from the Recordset to the screen is handled by the formatter property. The reverse is handled by the editor property and the corresponding variety of BaseCellEditor set on it.

My suggestion is to sum up all this different transformations in a single 'type' property in the column definition, which would be an index into a hash of entries with the following structure:


The 'server' and 'screen' levels could be dropped and the tree collapsed one level there, since the property names under it don't match, but I wanted to show it like this to make it clearer. The 'packer' would be the transformation from the Recordset to the server. Those with null values might as well be undefined.

Two date types might be offered. The current date parser uses JavaScript's own date parser but most of the time, the data comes from a database server and the default SQL format for dates is YYYY-MM-DD HH:mm:ss.nnnn so one date type would use the JavaScript parser, the other a parser for SQL dates.

Why is there a sortFunction? Sort uses the data as stored in the Recordset to do the sort, which is usually the correct thing to do, you want dates sorted chronologically, not by month first if you use mm/dd/yyyy format. However, if you are using a dropdown editor encoding, say, American states names into two letter codes, the user would expect to see New York before North Carolina though their codes are NY and NC which is what the default sort function sees, would make sort put them the other way, like WI and WV, AL and AK and many others.

Why the 'packer' property if DataTable doesn't use it? Because the implementor will have to use it at some point. If there is any editing, it will have to go to the server eventually. Since adding the asyncSubmitter function, the DataTable has gone a step closer to sending data back to the server. Implementors setting up an asyncSubmitter need the packer (actually, the raw and packed values might already be passed as arguments) and the parser as well, in case the server sends the data changed in any way.

The parser now belongs to the DataSource but right now the DataTable can easily access the DataSource fields array and change it and add the missing parsers. Moreover, the DataSource might not need to have a fields list at all. The DataTable might build it for the DataSource from the column definition. It only needs a couple of flags added to the column definition. 'visible', when false (default is true) would tell the DataTable that the data has to be parsed by the DataSource but not shown. 'madeup' or something a little bit more appropriate, would mean the data does not come from the DataSource but is made up by the formatter.

The 'editor' property might better be renamed to something like 'input' since it would involve more than simply the subclasses of BaseCellEditor. It makes no sense that if you put a plain checkbox in a cell, you are on your own. The 'input' property then should be able to specify both BaseCellEditor children and controls for direct input.

These 'formatter' and 'input' definitions should allow for row editing. The implementor should be able to decide whether to pop up a single cell editor or a row editor form. The default row editor would use fieldsets to group nested cells and the inputs defined for the types. In fact, the row editor would be nothing but an instance of a possible DataForm type. DataCells deal with fields, DataForms with Records and DataTables with Recordsets. The current column definition would be more of a property of the DataForm than of the DataTable, the DataTable being an aggregation of Records editable either via DataForm or DataCell.

The steps to define a DataTable would then be: check that you have Types to handle all your data and add those missing, define your column definitions using those types, your DataSchema and DataSource and finally the DataTable.

Types should not be something rigid, the implementor should be encouraged to define a bunch of types for his whole set of data for all his pages. If his dates are coming from an SQL server, it is unlikely that they will come Unix style. If his booleans come as 0 and 1, or "true" and "false" or whatever, it will usually be like that all the time. He can later arrange them in different ways in the different tables that might make up his application, but the types themselves will always be but a few.