Re: DB_DataObject and Structures_DataGrid integration
| From: | Olivier Guilyardi | Date: | Fri, 13 Aug 2004 12:40:14 +0000 |
| Subject: | Re: DB_DataObject and Structures_DataGrid integration | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-32608@lists.php.net to get a copy of this message | ||
Justin Patrin wrote:
On Thu, 12 Aug 2004 17:53:45 -0400, Andrew Nagy <asnagy@webitecture.org> wrote:I think there is a confusion between the Edit button which has a dedicated column, and the actual Form. It makes sense to be able to add such "Link Columns" for any of Edit, Update, Buy, etc... But, I don't see the point with saying : "this record is editable, this one is not". I only see this alternative : - Or _no_ record is editable : this is the traditional grid with an optional Edit button which takes you to a form - Or _all records are editable : this would turn the grid into a multiple records form, very similar to a spreadsheet About the "Link column" what about this : $column = new Structures_DataGrid_Column_Link("Edit"); $column->attachEventHandler("edit_callback_function"); $datagrid->addColumn($column); $column = new Structures_DataGrid_Column_Link("Delete"); $column->attachEventHandler("delete_callback_function"); $datagrid->addColumn($column); Event-based stuff, as .NET. The GET thingies are handled transparently. The prototype would be something like : callback_function($record_key)I am referring to the record edit pages. The fact that it is editing one record is not what I am talking about, it is the table layout not the content i am referring to. | Address | Phone | Edit --+---------+-------+------Ok, it makes some sense, but it makes more sense to me to edit per-record, not per-column. In fact, part of the idea was to be able to edit multiple records at once (possibly all displayed).1 | | |--+---------+-------+------2 | | |--+---------+-------+------3 | | |For example, let's say I want to edit the address for every record, I would use the editable column for the address column. Now let's say I wanted to have a link for every record in the edit column. I could use a hyper link column as the column class.
Yeah this is very smart about DataObject, and DataGrid definitely has to transparently query the DO about column types and display the proper type of control (drop down list, text field, etc...).The same argument could be made for making an editable record. For example if I want to edit every column for record number 2. However, the reason I feel the way this should be done via a column class, is due to the data types. Let's say addresses are dropdowns and phone numbers are text boxes, I would need to define this per column.It's already defined per-column in the db.ini file and the links.ini file for DB_DataObject. In addition, FormBuilder already creates select boxes for the links. This is all done, tested, and working code in DB_DataObject_FormBuilder.
Why limiting the editing on a per-record basis ? For example, at the database level you usually grant permissions to the whole table, no to records. Of course, in some more complex situations, you can have an owner for each record, so that each user can only edit certain records. Is this the kind of issue you want to address ? -- ogNow the trick is, using my paradigm, how do you limit the editing on a per record basis.Using your paradigm, I don't see how you can. If only columns are editable, then only columns are editable. BTW, looking at the latest phpMyAdmin, I still don't see editable columns. http://www.phpmyadmin.net/phpMyAdmin/ IMHO, DataGrid should focus on editable records, not columns.