On Feb 6, 2006, at 2:13 PM, Max Ischenko wrote:
To continue the topic from "cleaned up widget API" thread.
I wrote:
OTOH, may be a good route could be to have a streamlined DataGrid
class
that knows nothing about SQLObject's model and/or SelectResults (and
takes a single required ctor arg: fields) and then add, say,
FastDataGrid
subclass that can derive fields from model (like my NewDataGrid
version
did) or compute them at runtime (like yours version did).
Alberto Valverde wrote:
I agree with this. I can see that DataGrid as it's currently
impemented
could be used also for a non SO grid, which isn't very specific... I
favor a refactoring out of the grid basic stuff into a separate
subclass
that could be used for displaying any kind of "gridded" data
structure
(like a parsed logfile, for example) and have a different grid
for SO
SelectResults.
How about the following plan.
Step 1. Take current DataGrid implementation (by Alberto/Kevin),
simplify it a bit by assuming it is always applied to SelectResults
data (as it originally did), remove docstring that explains how to
use it for arbitrary dataset and rename to FastDataGrid. Update
DataController to use FastDataGrid.
Step 2. Take my NewDataGrid implementation, move it from fastdata
to widgets package and rename to DataGrid. I strip any logic to
deal with SelectResults data (model argument, columns_meta) and
update docstring.
Step 3. Update DataGridWidget page to document both widget classes
and explain the differences.
In my view, FastDataGrid can be seen as a 'final' class, used by
fastdata to quickly build stock UI while DataGrid is a generic
'grid' widget built with extensibility in mind. FastDataGrid
focuses on providing something workable with the least (zero)
efforts from the user while DataGrid focuses on giving the most
flexibility to handle a widest range of real-world use cases.
I'm not 100% sure this is a way to go so I'm eager to know what
others think.
Max.
What I meant by a refatoring was something like:
class DataGrid(someKindOfWidget):
""" Logic to display a gridded data structure. Completely model
agnostic"""
class FastDataGrid(DataGrid):
""" Logic to take a searchresults instance and "pump" it into a
DataGrid (with headers,
edit/delete buttons, etc...) """
I think and confused the terms, where I said "subclass", should have
said "superclass", sorry.
However, whatever decision is made, I think both grids should offer
the possibility to change headers, columns, at display time too (via
update_data).
Regards,
Alberto
