Re: DB_DataObject and Structures_DataGrid integration

Markus Wolff wrote:

Olivier Guilyardi wrote:

Structures_DataGrid is .NET'ish. And browsing the related .NET documentation, I can see there are many data providers, but it always end up with a : datagrid->datasource = someDataProvider. According to this, you definitely are right about adding a driver to DataGrid. Do you think I can do this by creating a new package ? Or should I modify DataGrid ?

How about this: Just pass the datasource object (or array or resource or whatever) to a factory method, which looks at the type of the datasource (using get_class, is_array etc.) and then returns an instance of the appropriate DataGrid class, like Structures_DataGrid_DataObject, Structures_DataGrid_Array etc.

This is the .NET approach, lots of abstraction layers, the DataSource can be anything, some layer out there is going to figure it out... sqlAdapter, dataSet, dataView, dataBinding, etc... I think the DataObject_FormBuilder approach is more simple and effective. So what about a DataObject_DataGrid : the datasource is always a DataObject, and the renderer always a DataGrid. FormBuilder provides getForm(), what about getDataGrid() ? Then, you can play with the returned DataGrid, do HTML, Smarty, whatever. Now, instead of a DataObject_DataGrid::getDataGrid() method, there could be some DataObject_DataGrid::create() factory method, that would return a DataGrid already set up and filled with data. I don't know...

It's pretty easy to do and very effective. If you can't use a factory method, make a setDatasource() method which also does type checking and then makes an instance of a suitable adaptor class that the DataGrid can use as a general interface to datasources. The real datasource will be passed to the adaptor class and the adaptor object will be used as the datasource.

The problem there is that DataObject obeys to a certain paradigm, and I think it's gonna be hard and heavy to abstract that again. Too much abstraction I think... To me, when starting a project, you got to choose a data handling paradigm. Once this design choice is made, you don't go backward, you assume it. Now, if you ended up with choosing DataObjects, you can pick some specialized renderer : DataObject_FormBuilder, DataObject_DataGrid, etc... Now, following the steps of Justin, we could implement DataObject_Frontend, packing all these renderers, to form some kind of plug and play package, while retaining the smart customizing abilities of QuickForm, DataGrid, HTML_Menu, etc... -- og