Re: DB_DataObject and Structures_DataGrid integration

Justin Patrin wrote:

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 have a much better understanding of the topic now, sorry for showing late to the party :) The biggest concern I have with the current topic, is it is all based on DataObject, I think this discussion has lead to a bigger issue and should not be primarly focused on DataObjects. Let's also keep in mind that (as we saw from Jackson's example) DG can use INI files, XML files, other DB abstraction record objects, etc. These other sources may be beneficial from some of these ideas that are being discussed. Maybe SDG needs a new "internal" data structure, instead of an array? Am I way off base, or is this in the right direction? Andrew