On 16 Jul 2006, at 05:59, Karoly Negyesi wrote:
Think of it. It becomes a habit very quick to press Confirm, and also "of course I really want to delete it, that's why I pressed the button". A day later when you realize that this deletion was not a good idea, you can almost hear the whining of the computer "but you pressed confirm!". "A computer is like an Old Testament god, with a lot of rules and no mercy" -- how does this image mate with the friendly smiling face we have choosen as our icon?
Just got got back from a short trip. I reviewed the module and posted an update at http://drupal.org/node/35422. My problem with the trashbin patch is the way it works. I'm not convinced that it should transfer deleted records to a dedicated table. Right now, the trashbin patch stores deleted records in a separate table in serialized format. This is a little bit awkward as it has to circumvent the auto increment IDs or the sequence table when re-injecting the data. It's both ugly and clever, but at the end of the day, it doesn't feel right to me. Why don't we add a status-field with two states -- STATUS_ACTIVE and STATUS_DELETED -- to each of the database tables with records that want to take advantage of the trashbin functionality? Then, the trashbin patch might be a lot easier to grok -- and from an architectural point of view, less awkward. It wouldn't be particularly clever but that is OK: it is super-easy so there is no point being clever to begin with. I'd like to see us explore this path instead. Plus, this has a number of advantages. Most of all, we'd still able to query deleted data. For example, the filter form on the administer content page (?q=admin/content) would allow us to access delete nodes and we'd be able to use advanced query methods like 'show all deleted nodes from user Joe with the taxonomy term 'Apple'. That is, we get to reuse a lot of the existing UIs and modules. -- Dries Buytaert :: http://www.buytaert.net/