Hi Max,
On Feb 5, 2006, at 1:02 PM, Max Ischenko wrote:
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).
I don't see why it can be harmful. Computing headers, etc... at
runtime opens the possibility to a non-model-specific grid which can
be used for displaying any kind of SelectResults with the same
controller/grid. Anyway, I haven't got a real use-case for this right
now so I can't back up my opinion any further.
My intention when porting it was to keep the interface and behaviour
intact, so no functionallity I wasn't using (but somene might be,
like non-SO grids) was lost. This way migration wouldn't be so
painful (probably Randall doesn't think alike, though ;)
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 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.
Anyway, I *believe* the current behaviour (overriding fields at
display time) should be preserved, as I think would keep in line with
the new widgets' capabilities, quoting Kevin previuously in this thread:
"The other plus that came out of this plan (which is not yet
implemented, but also not hard) is the ability to override everything
at display() time. "
Regards,
Alberto
