Re: DB_DataObject and Structures_DataGrid integration

Andrew Nagy wrote:

Well since I have worked with many of Markus Wolff's ideas when planning and designing the DataGrid, I do like his ideas. The DG, in my mind, is a layer between the interface and the datasource. However, The DG has "drivers" (or whatever you want to call them) for the interface and datasource. I personally would like to see more development in the datasource driver department.

I second this. When your goals can be achieved by adding additional datasource drivers, this is the way you should go.

But I am still confused why Structures_DataGrid_Record_DataObject is not meeting your needs? Why would you want to bind an array of DataObjects when you can do something like the following: $user = new User(); if ($user->find) {

    while ($user->fetch()) {
        $dg->addRecord(new
             Structures_DataGrid_Record_DataObject($user));
    }

} or even: $user = new User(); if ($user->find) {

    while ($user->fetch()) {
        $dg->addRecord($user->toArray());
    }

}

Hmm... I must admit that I haven't looked at DataGrid for quite a while so the way how records are being added wasn't known to me. From a quick view on this example code, I fear that this method will produce a lot of overhead (memory-usage). Here's what I would do: Just add one DataObject (or DB_Result object or whatever else) as the DataSource - but do nothing with it yet. At the point where the HTML output for the DataGrid needs to be rendered, you access your DataSource again and build the output directly from iterating through the records. For DataObject, this is being done with ->fetch(), for DB_Result with ->fetchRow() etc. - the point is, if you iterate through the data source, you produce the output directly. You do not copy all the values into one large array which would need to be iterated over yet again at a later stage, thus you save on both processing time and memory usage. CU Markus