Re: DB_DataObject and Structures_DataGrid integration

Olivier Guilyardi wrote:

I do not want bind() to accept an array of dataobjects, but a _single_ dataobject. So what happens when you bind() a dataobject ? 1 - the DataGrid checks if some (query string) input is coming back

    from the user :

- if the user clicked on some the column headers, to sort the data,

    we pass the sort field and direction to DataObject::orderBy()

- if the user is paging through the data, we determine which page

    we're to display, and pass the corresponding information to
    DataObject::limit()

2 - the DataGrid performs a DataObject::find() and _as_many_

    DataObject::fetch() as required

3 - It can now fill multiple records, as well as setup the columns. All of this happened transparently. You just typed "bind".

But this can all be done with very few lines of code: if ($_GET['orderBy']) {

    $user->orderBy($_GET['orderBy']);
    if ($user->find()) {
        while ($user->fetch()) {
            $dg->addRecord(new S_DG_R_DataObject($user));
        }
    }

} Am I missing something?

I do urge you or others to help contribute to Structures_DataGrid!

That's fine for me. What do you think of a DataGrid_Source abstract class as I described in my last answer to Justin ? Then inside a DataGrid/Source directory, DataGrid_Source_DataObject, DataGrid_Source_FooBar, etc...

To me it just seems like a cleaner design to add record by record to the DG instead of the whole mosh. The bind exists for the quick and dirty approach if the app programmer already has an array that is suitable. If we add an entire datasource, DG will loose it's concept of a layer between the datasource and the interface. It will make DG more of a layer ontop of a datasource rather then something more flexible. I am not trying to damper your ideas, just trying to argue them out to find the best solution :) Andrew