Re: DB_DataObject and Structures_DataGrid integration

On Tue, 10 Aug 2004 23:03:16 +0200, Olivier Guilyardi <ml@xung.org> wrote: > 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. True, but I display frozen forms, so it's basically just text. > > >>>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 You're going to want to use fb_fieldLabels. This changed in the newer CVS versions of FormBuilder and will be in the next release. This is to seperate FormBuilder properties from normal data properties. > > 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... Sounds good to me. FormBuilde actually has a similar useForm method which allows you to use a pre-existing HTML_QuickForm. I think this would all be very useful. Of course, it makes more sense to me to have DataGrid support DB_DataObject with a different datasource... > > > 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 ? > For example, there is this function: getDataObjectSelectDisplayValue(). Pass it a dataobject and you get a return of the "display value" for that dataobject. This uses the fb_selectDisplayFields array (should be renamed soon to fb_linkDisplayFields or something similar) to to make a string which "identifies" the record. It's used for populating the link drop-downs. > -- > og > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--