"Max Ischenko" <[EMAIL PROTECTED]> writes: > My non-authoritative opinion that in this case DataGrid flexibility of > adapting to different model classes is actually harmful. Passing the > model explicitly is IMO better and safer. Plus, only a trivial change > required to DataController to init list_widget that way (it has > sql_class available at ctor).
So, if we pass it directly, how can we filter results? Lets suppose I want to filter data by sex or age or something else. If I pass a SelectResult then I can filter by any field and using anything supported by SQLObject. If we pass the model directly and it isn't possible to filter results before using them on the grid one would have to create several views and put those on the model... > 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). I think that subclassing for filtering results is not a good design here, specially because it is very simple to have these results filtered and in the form of an iterator. -- Jorge Godoy <[EMAIL PROTECTED]>
