Re: Proposal - HTML_DataGrid - Again
| From: | Hans Lellelid | Date: | Mon, 09 Feb 2004 15:16:23 +0000 |
| Subject: | Re: Proposal - HTML_DataGrid - Again | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-25559@lists.php.net to get a copy of this message | ||
Andrew S. Nagy wrote:
The advantage with this solution is that you are not building your tool to support specific packages, but you are making it possible for those packages to integrate with your tool in a way that won't result in any inefficiency. (I might be missing something, but in order to use DataGrid paging, wouldn't I need to pass entire resultset to DataGrid?) HansAnd as an application developer, I don't really want to care about what I give to the DataGrid. If the data needs to be paged, the DataGrid will know how to do it. Having an adaptor class for the datasource will make adding a paging feature easy, and it can be implemented differently for each type of datasource.It seems that the data should be massaged with DB or DB_DataObjects. Im not sure implementing a DataManager is best because I feel that I would end up porting something like DB_DataObject into the DataGrid, which is what I don't want to do. Maybe there's a compromise solution where you define an interface (or if for PHP4 a class that will be extended) for DataGrid input data. This interface could make it possible for DB layers to provide data -- as well as any applicable paging information -- to your class w/o you having to build any special support for particular data layers. You could have some method like DataGrid->load() that could be passed an array or a class that implemented this interface. I would need to look more at how your code handles paging, but off the top of my head I could imagine such a class having methods like ->getTotalRows() getRowsPerPage() getCurrentPage(), and implementing an iterator so that you could use it in foreach().