Re: DB_DataObject and Structures_DataGrid integration

Justin Patrin wrote:

The thing about the frontend is that it's all customizable through the FormBuilder options in your DataObjects. You can change the rendered fields, field labels, etc. in the DataObject and it will be automatically changed in the Frontend. I did plan on making it more plug-and-play so you could supply your own rendering class(es), but I got basically no interest, so I've been concentrating instead on FormBuilder development.

My new component would help Frontend's development, I think. Mixing HTML_Menu, DataGrid and FormBuilder would be nice.

I don't see the point with forcing your forms to act on single records : think of a spreadsheet-like form...

Well, FormBuilder (at least orignally) was supposed to make a form for editing or inserting a single record. In point of fact, that's what it's still for. I hacked my way around it, freezing the forms and making a special QuickForm renderer to make a table. It could be very possible to make this work better.

FormBuilder does a good job yet. Multi-record forms are not very convenient anyway.

Sounds like you should be adding a driver to DataGrid to me. Perhaps you could add a FormBuilder renderer as well so that you can use FormBuilder's link displaying capabilities.

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 ?

Well, I would say work on it as if it's part of DataGrid (i.e. put it in the correct directory), then, once you hae something working, send it in to the DataGrid maintainers.

Let's take : $datagrid->bind($dataobject); This is the same as setDataSource(), as Markus Wolff proposed. It also is the .NET way. Additionally, it's a very clear statement : "bind" says it all. This bind() function currently accepts a simple array, and as Markus said, with some get_class($arg) it is very easy to make it accepts anything. But the DataGrid code is just too nice, I don't dare to touch it. I would need to heavily modify it, because nothing is ready for bind() to support bilateral interactions : it currently reads an array, I need it to read a DataObject but also to instruct it how to sort and limit the data. The other approach, that I developed in my answer to Markus, is to do: $dog = new DB_DataObject_Datagrid($dataobject); $datagrid = $dog->getDataGrid(); Or : $datagrid = DB_DataObject_DataGrid::create($dataobject); This is a similar approach to FormBuilder, as an interactive renderer for a DataObject. It has a very practical avantage : I can develop DB_DataObject_DataGrid as a standalone package and go through the proposal process. But, it would be very nice, if my proposal is accepted, that the DataGrid maintainers can easily plug it into the DataGrid::bind() method, if they wish. So, in addition to creating a DataGrid from scratch, with the getDataGrid() method, one could do : $dog = new DB_DataObject_DataGrid($dataobject); $dog->setDataGrid($datagrid); This last call, passing an already existing $datagrid as a reference, should be called from DataGrid::bind() as $dog->setDataGrid($this); Actually, the only difference between getDataGrid() and setDataGrid(), is that the former creates a DataGrid object, while the later uses an already existing one. Both of these methods would call a private one, say _handleDataGrid(), to : - ask the DataGrid if and how the user wants her data sorted - retrieve the DataGrid's pager, and ask it which page is to be displayed - according to this, possibly perform some DataObject::orderBy() and limit() calls - fetch the data from the DataObject, as well as the fieldLabels property - fill the DataGrid What do you think of this, Justin, Markus ? Is there any DataGrid maintainers around ? It's not clear for me if this setDataGrid($this) call is a good idea or not...

You *may* want to look into using some of FormBuilder's functions for things like getting text for linked records. I can help you with that if you like.

By linked records, are you talking about foreign keys ? I've not yet been thinking about these... What do these FormBuilders functions exactly do, and where can they integrate with the approach I describe above ? -- og