Re: DB_DataObject and Structures_DataGrid integration
| From: | Justin Patrin | Date: | Thu, 12 Aug 2004 17:28:44 +0000 |
| Subject: | Re: DB_DataObject and Structures_DataGrid integration | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-32592@lists.php.net to get a copy of this message | ||
On Thu, 12 Aug 2004 08:51:30 -0500, Jackson Miller
<jmiller@magazines.com> wrote:
> Justin Patrin wrote:
> > The current way of doing things has an array for data. *All* of the
> > data is stored *at once* in the DataGrid. This is bad because it:
> > 1) Takes lots of memory
> > 2) Means you have a tim-consuming query / fetch cycle cofr *every*
> > call of the script
> Exactly. I have my own work around for this but it is not DG only.
>
> > DataGrid pages the data, so why not make it page intelligently by only
> > getting the data it needs? Also, DataGrid has *built-in* paging and
> > sorting. You *can* use the $_GET vars when you query for your data,
> > but that's a hack. DataGrid should be teling your data source to give
> > it the data it needs.
> I am not so sure this is a good thing. If SDG not only displays the UI but
> also processes incoming requests ($_GET['page'], $_GET['orderBy']) then we
> have to do something to make the SDG request vars not so global. Mybe
> something like this:
> $_GET['sdg[page]']
> $_GET['sdg[orderBy]']
> $_GET['sdg[direction]']
> (order by and direction should probably be arrays themselves but...)
But DataGrid is already handling this internally, isn't it? You feed
it a large array and it orders the data and gets the page that you're
currently reading. This is all internal.
Looking at the example, it looks like you have to pass the GET params
in manually, but it is still DG which is doing the sorting/paging.
Passing these parameters down to the data source to get the records
needed just makes sense to me.
>
> On Thursday 12 August 2004 08:22 am, Andrew Nagy wrote:
> > The biggest concern I have with the current topic, is it is all based on
> > DataObject, I think this discussion has lead to a bigger issue and
> > should not be primarly focused on DataObjects. Let's also keep in mind
> > that (as we saw from Jackson's example) DG can use INI files, XML files,
> > other DB abstraction record objects, etc. These other sources may be
> > beneficial from some of these ideas that are being discussed.
> I completely agree. Now is a good time to mention that we (myself and Marcus
> Whitney) have also integrated DB_QueryTool with SDG to allow complex
> searching on SDG data. We have incorporated paging, sorting, limiting, and
> conditional getting (where) of SDG data. It is also really easy to create a
> multi-dimensional array from the result set and use $dg-bind to set all of
> the records in one-fell-swoop. I understand the need/desire to use bind in
> other ways, but this one works really well already. so...
>
> >
> > Maybe SDG needs a new "internal" data structure, instead of an array?
> Nope. PHP has some of the most powerfull array handling of any language.
> Let's stick with the stregnths.
>
> -Jackson
> >
> > Am I way off base, or is this in the right direction?
>
> >
> > Andrew
>
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--