Re: Proposal - HTML_DataGrid - Again

"Markus Wolff" <wolff@21st.de> wrote in message news:40210D92.3030800@21st.de... > What I'd do is not have a single RecordSet class but one special > recordset class for every type of datasource - it makes adding new > datasources way easier. Those classes must all provide the same > interface; essentially, they must implement an interator and means to > retrieve the names/types of the columns inside the record. Markus, I am still batteling over the design for this. It seems to me that for optimal abstraction, I would always want the datagrid to only allow one datatype, something that it understands (in my instance an array). It seems that while a class for each different data type seems like a nice design, for each of the different types discussed (DB_DataObject, DB_Result, etc.) it's only one line of code to convert each record to an array. A class to handle each may then make it very bloated. If I wanted to add a DB_DataObject as a record to the datagrid, I would convert it to an array myself so there is no unneccessay code. $this->_record = $dbobject->toArray(); or $this->_record = $dbrecord->fetchRow(DB_FETCHMODE_ASSOC); Also, you mentioned in an earlier posting (Jan 10th) not wanting to load the entire dataset into the datagrid, this can be easily done with the limit clause and using the variables that are sent across the querystring by the datagrid in it's paging. As I am still on the fence about how to handle the dataset, do you have any strong points about why to use a data manager for each type? Thanks for your help Andrew