Re: DB_DataObject and Structures_DataGrid integration

On Wed, 11 Aug 2004 17:52:31 +0200, Olivier Guilyardi <ml@xung.org> wrote: > Jackson Miller wrote: > > The DataGrid maintainer is around. It may take a couple of days, but he will > > respond. I am not sure how active he is on pear_dev. > > He's right here :) > I'm glad this discussion is moving along, this seems like it can be an exciting addition to DataGrid. > > I have integrated dataobject and datagrid numerous times when building CEP > > modules. I have also added HTML_QuickForm into the mix. Re-usable DG/DO > > integration has been on my todo list for a while, but time is a limited > > resource for me. > > What are these "CEP" modules ? I want to implement this DataGrid/DataObject > integration to increase my productivity for a specific project I'm working > on. So, hopefully, it will save some of my time while contributing to PEAR :) > > > The main difficulty in using DataGrid with DataObject has to do with the > > pager. DataGrid determines the number of pages based on the number of > > records. When working with large database tables you don't want there to be > > DataGrid records for every record in the database. Once you use LIMIT in > > DataObject, paging is broken, and sort is pretty worthless. > > Definitely, this is why the DataGrid has to call DataObject::limit() by itself > when paging. Something like this might work: //to get # of records $count = clone($this->dataObject); //or whatever it is in DataGrid $numRecs = $count->find(); //when you're ready to pull data $this->dataObject->limit(...); //using DataGrid values $this->dataObject->orderBy(...); //again, using DataGrid values if ($this->dataObject->find()) { while ($this->dataObject->fetch()) { //populate DataGrid's page of data } } I haven't looked at the DataGrid code myself, so I don't know how hard this will be to integrate into the current code. I would suggest having multiple backends which bind() uses. Since bind() is used on an already instantiated object, you can't easily use a factory. However, you could instantiate a $this->_dataSource based on the type of the input to bind and change the internal DataGrid calls to use that instead. All current array-based functionality would have to be moved to something like DataGrid_Source_Array. Then you could have a DataGrid_Source_DataObject. > > > So I have had to run two queries, one to get the number of records and a > > second to get the records that will be displayed. This doesn't make sense if > > you have two pages of 50 records each (might as well select them all), but it > > is necessary if you have a million records in the DB. > > By the way, if you work on big an complex databases, take a look at my #2086 > bug report. The DataObject generator now supports database views. > > > Another shortcoming of DataGrid (especially when compared to .NET) is the > > ability to make rows "editable" in the DataGrid. I have hacked this together > > for my own needs, but it would be nice to see it available in the package. > > I believe this is related to the FormBuilder. This is related to FormBuilder, but it all depends on how you want ot support this. I've done some fancy Javascript stuff before to dynamically create a form in a table. This could be done, if people are interested. I could even write such a beast. :-) For a simple alternative, DataGrid could add an Edit column which has a link. When the user clicks the link, it displays a FormBuilder QuickForm. This could easily be controlled by an option to DataGrid. > > I don't know how far PEAR could go in trying to "clone" .NET. There should be > some in-depth article on the subject. It seems like .NET provides some > smart features/paradigm with these web controls ; _lots_ of research behind > it I think. Never used .NET myself, but I like the way that this package is going. > > -- > og > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--