Re: DB_DataObject and Structures_DataGrid integration

From: Date: Wed, 11 Aug 2004 12:29:17 +0000
Subject: Re: DB_DataObject and Structures_DataGrid integration
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-32545@lists.php.net to get a copy of this message
Justin Patrin wrote:
On Tue, 10 Aug 2004 23:03:16 +0200, Olivier Guilyardi <ml@xung.org> wrote:
       $dog = new DB_DataObject_Datagrid($dataobject);
       $datagrid = $dog->getDataGrid();
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);
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...
I'm not sure what you mean here about the datasource, but I guess this is about adding some classes to DataGrid instead of creating a new package. The problem is that it's not only a matter of _adding_ a datasource to DataGrid. In the current DataGrid code, there's no such thing as datasources for the whole grid. There are the following _record_ source classes : Structures_DataGrid_Record_DataObject Structures_DataGrid_Record_DB And these, given their location in the classes hierarchy, are totally irrelevant when it comes to provide a two-ways interaction between the whole DataGrid and a DataObject, as I wish. At the grid level, the only "datasource" implementation consists of :
    function bind($rs)
    {
        if (is_array($rs)) {
            $this->recordSet = $rs;
            return true;
        } else {
            return new PEAR_Error('Recordset must be an associative array');
        }
    }
I've just sent a mail to the DataGrid maintainer to invite him to participate to this thread. He may be on vacation... Markus talked about some classes like DataGrid_Array, DataGrid_DataObject, etc... But it looks to me as I would first need to create a DataGrid_Source abstract class, similar to the DataGrid_Renderer class. Then real sources would come into the DataGrid/Source directory... I have the intuition that this abstract source thing is tricky. I must also confess that you, Justin and Markus, FormBuilder maintainers, are very responsive, and that influences me to prefer a DB_DataObject_DataGrid package (or GridMaker, whatever), which is somewhat similar to FormBuilder.
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.
Wether I choose to implement DataGrid sources, or a DataObject_DataGrid package, how should I use these functions ? Extend or decorate some of the FormBuilder classes ? I thought my code would only depend on DataObject and DataGrid... Shouldn't some of these functions go inside the DataObject classes ? -- og

« previous php.pear.dev (#32545) next »