Re: Proposal - HTML_DataGrid - Again
| From: | Hans Lellelid | Date: | Mon, 09 Feb 2004 14:16:28 +0000 |
| Subject: | Re: Proposal - HTML_DataGrid - Again | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-25552@lists.php.net to get a copy of this message | ||
Hi-
Andrew Nagy wrote:
"Markus Wolff" <wolff@21st.de> wrote in message news:40210D92.3030800@21st.de...If you're writing for PHP5 then you may note that the passed in value simply needs to implement an (SPL) iterator. That provides some additional flexibility. So, I would agree with you -- keep the input simple. For example, I'd like to also support creating DataGrid objects from my Creole/Jargon (http://creole.phpdb.org) DataSet class. I would think it would be my responsibility as calling package to make sure my data were in the correct format. E.g. $q = new Query($conn, "SELECT * FROM mytable"); $dg = $q->getDataSet()->getDataGrid(); // etc. On a side note, it would be nice (and maybe this has been mentioned already) to have a single method to set all the field key => name mapping -- using assoc array. Also, to make specifying columns optional (this may already be the case, but I thought I read that you had to setup the columns) so that the tool could be integrated into CMS-type systems where there wouldn't be any hard-coded expectations for which columns were being displayed. I haven't spent too much time looking at the code, but I was going to also suggest that things like links (href) should not be specified using the API; instead (IMHO) these should be part of a template or something. I do not have much experience w/ DataGrids in .NET, but I think what I'm thinking is something like the "ItemTemplate" / "EditItemTemplate" aproach. Perhaps it works better in XML than in PHP API :) HansWhat I'd do is not have a single RecordSet class but one special recordset class for every type of datasource - it makes adding new datasources way easier. Those classes must all provide the same interface; essentially, they must implement an interator and means to retrieve the names/types of the columns inside the record.Markus, I am still batteling over the design for this. It seems to me that for optimal abstraction, I would always want the datagrid to only allow one datatype, something that it understands (in my instance an array). I was going to say this also. Yes, I don't think that it's the job of DataGrid to massage input types into some common format. If DB / MDB / DB_DataObject wants to support DataGrid natively, then it can implement the necessary method(s) to get data into the right format. Otherwise, as you said it's not too much work to just call the toArray() method.