Re: DB_DataObject and Structures_DataGrid integration

On Thu, 12 Aug 2004 03:28:30 +0200, Olivier Guilyardi <ml@xung.org> wrote: > Justin Patrin wrote: > > > Andrew Nagy wrote: > >> > >>But this can all be done with very few lines of code: > >> > >>if ($_GET['orderBy']) { > >> $user->orderBy($_GET['orderBy']); > >> if ($user->find()) { > >> while ($user->fetch()) { > >> $dg->addRecord(new S_DG_R_DataObject($user)); > >> } > >> } > >>} > >> > >>Am I missing something? > > You forgot : $user->limit(($dg->getCurrentPage() - 1) * $LIMIT, $LIMIT); > > One line more ? Ten lines ? It does not matter to me. I need components > which relies on coherent paradigms. > > >>If we add an entire datasource, DG will loose it's concept of a layer > >>between the datasource and the interface. It will make DG more of a > >>layer ontop of a datasource rather then something more flexible. > > I think you're here talking about something I felt when reading DG code. > It's nice :) It's doing a well-defined job : it's everything but bloated. > If we add a global source, it will get more complex, there will be > some risk that it gets bloated, your code will somewhat quit childhood ;) > > But please, consider this : the DG won't lose flexibility. You're still > free to add per record _or_ global sources. > Well, using per-record should by default use the Array data source. I completely agree, you're adding flexibility. You *may* incur a slightly longer run-time, but a good design minimizes this while maximizing flexibility. For instance, the factory() method that many packages use loads only the file(s) needed and gives you direct access to the methods. Since DG was not started with this paradigm, we can't switch to it without breaking BC. Perhaps all of this should be in DG2 instead....but that's for the DG lead to decide. The internal data source way I mentioned earlier will incur an extra object instantiation and an extra function call in various places, but I would think that the flexibility would be worth it, especially with FormBuilder to use as a resource. > About "drivers"... Currently, DG_R_DO does not handle : > > - retrieving DataObject::fieldsLabels (labels != field names) > - handling values pointed by foreign keys > > Now, say you add these features to DG_R_DO... A global DG_Source_DO > can reuse them. This is the driver you want. You code it once at the > row level, the global source reuse it. > > > I don't think you quite inderstand the paradign that DataObject works > > under. You set up your query parameters with it, run a find(), when do > > while($do->fetch()). The same object is used for all of the records. > > It supports sorting (orderBy()) and limiting of returned data > > (limit()). If DataGrid had a backend which *understood* this, it could > > get all the data it needs and only load the records it needs to > > display the current page. This is how a datasource should work. > > I think Justin is really right here. You don't see clearly what a DataObject > is, you think it's yet-another-kind-of-array : > > class Structures_DataGrid_Record_DataObject > > [...] > > function setRecord($data) > { > if (get_parent_class($data) == 'db_dataobject') { > parent::setRecord($data->toArray()); > } else { > return new PEAR_Error('Invalid data type. Data must be a DB_DataObject > record'); > } > } > > The way you use toArray() here makes me believe you don't get how dynamic > is a DataObject. > > >>I am not trying to damper your ideas, just trying to argue them out to > >>find the best solution :) > > Do not hesitate to kick my ideas. If they're good they will resist :) > :-) A quick side-note. I think it's interesting that as the packages have progressed and the names have gotten longer, we shorten them to only the caps letters in their names. ;-) -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--