DataGrid refactorings
Max Ischenko
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.
Alberto Valverde
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
Kevin Dangoor
> 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.
Sounds like a fine idea. It's hard to know for sure how it'll work out
without actually trying it, so I'd say: give it a go and see how it
feels.
Kevin
Kevin
Max Ischenko
to FastDataGrid, please check it out (r679).
Some notes.
I also added widgets/templates/datagrid.kid to be used with plain
DataGrid class. It is intentionally simple to facilitate user's
extensions and contains no fast-links (edit/add/delete).
DataGrid introduces new DataGrid.Column type that allows one to define
additional properties (I use it to mark sortable columns in a grid).
Override fields at display time is also supported. FastDataGrid
realized as a subclass that simply extracts fields info from
SQLObjects' metadata and then passes to DataGrid for rendition.
Templates are passed new 'columns' variable which is a list of
abovementioned DataGrid.Column instances. I updated templates to use it
instead of collist/headers but those variables still passed for
backward-compatibility with existing user templates.
The documentation(*) has to be updated yet.
* - http://trac.turbogears.org/turbogears/wiki/DataGridWidget