Re: DB_DataObject and Structures_DataGrid integration

On Wed, 11 Aug 2004 15:17:17 -0400, Andrew Nagy <asnagy@webitecture.org> wrote: > 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? > If you'd read the rest of the thread....yes, you're 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 you add a big array or each record one by one, you're ending up with the *same* DataGrid. It makes no difference. We're talking about a different use for bind(). > > 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. It's already a leyer between the datasource and the interface. It's just not making proper use of the datasource yet. It will still work the same way for the current "array-based" model, this will just allow for other, smarter, datasources. The current way of doing things has an array for data. *All* of the data is stored *at once* in the DataGrid. This is bad because it: 1) Takes lots of memory 2) Means you have a tim-consuming query / fetch cycle cofr *every* call of the script DataGrid pages the data, so why not make it page intelligently by only getting the data it needs? Also, DataGrid has *built-in* paging and sorting. You *can* use the $_GET vars when you query for your data, but that's a hack. DataGrid should be teling your data source to give it the data it needs. I don't think you quite inderstand the paradign that DataObject works under. You set up your query parameters with it, run a find(), when do while($do->fetch()). The same object is used for all of the records. It supports sorting (orderBy()) and limiting of returned data (limit()). If DataGrid had a backend which *understood* this, it could get all the data it needs and only load the records it needs to display the current page. This is how a datasource should work. > > I am not trying to damper your ideas, just trying to argue them out to > find the best solution :) > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--