Re: DB_DataObject and Structures_DataGrid integration

Andrew Nagy wrote:

Olivier Guilyardi wrote: Help design the datasource driver for DO. Or think about the possibilities of a global datasource driver. My ideas are below for the idea of a global datasource driver. This concept removes the need for a switch detecting what source i am using. The downside is the class is not something that will "do everything" for the app programmer, making the programmer have to think about what "driver" to use. The good, no switch statement that needs to be updated every time we add a new data source as well as the extra processing time. I just came up with a simple decorator patter, let me know if you have any other better design ideas.

So I guess that the developer has to directly do : $datasource = new Structures_DataGrid_Source_DataObject($dataobject); Is that right ? That's ok with me, although I don't see no decorator pattern below. Additionnaly, why does S_DG_S_DO::fetch($source) accept this $source argument ? It already knows its source...

class Structures_DataGrid_Source_DataObject extends Structures_DataGrid_Source {

    function Structures_DataGrid_Source_DataObject($source)
    {
        parent::Structures_DataGrid_Source($source);
    }

    function fetch($source)
    {
    }

    function clear()
    {
    }

    function autoGenerateColumns()
    {
    }

} class Structures_DataGrid_Source {

    var $source;

    function Structures_DataGrid_Source($source)
    {
         $this->source = $source;
    }

    function fetch()
    {
    }

    function clear()
    {
    }

} My only request, please don't use one letter variables! I hate them and it makes sense to the creator but means jack to anyone else :)

No problem. I like to use one letter variables in both PHP and C, within short functions, but I agree it's sometime confusing. I'll read the PEAR coding standards again ;) -- og