Chad Phillips -- Apartment Lines wrote:
just to put everybody in the loop here: chx and i have been discussing the idea of a deletion API for drupal core, which would address killes' modular concerns as regards this functionality, as well as allow us to break out all the confirm code into a seperate module. what this means is that site admins would have the following options for a deletion workflow:
1. the current scheme: no trashbin, with confirm screens 2. trashbin with confirm screens 3. trashbin with no confirm screens 4. no trashbin, no confirm screens (for those who like to live dangerously!)
simply enable or disable either of the confirm.module or trashbin.module to get the desired combination.
in addition, the API would provide non-core modules with greater access to the core's deletion cycle (which is currently fairly closed)
My latest thinking: - The trashbin concept is a good idea and is core-worthy (with the usual rigorous review and such). Norman [1] and Tog [2] (to name two) agree that confirmation dialogs are often read-over, leading to unintended consequences [3,4]. - A delete API is a good thing. Everyone loves APIs. - Confirm screens (and later, a trashbin if in core) are basic functionality that users should not have to think about (see http://lists.drupal.org/archives/development/2006-07/msg00450.html). The confirm screens should be hard-coded into core (system.module if the API calls for adding them via hooks). - The best place to put the choice to disable confirm screens (if a modular trashbin is present for example) is in the API, so code can disable it as appropriate without the need for a UI element. A module can add the UI for disabling confirm screens if a particular site needs it. - The delete API idea does make trashbin able to live in contributions, but remember that moving from contributions to core is rarely smooth. - As always, if there is a large amount of code that is added but not used much, put it in a .inc file next to the relevant module and include it on demand. [1] http://en.wikipedia.org/wiki/Donald_Norman [2] http://en.wikipedia.org/wiki/Bruce_Tognazzini [3] Norman, _The Design of Everyday Things_ p 113: "The user has requested deletion of the wrong file but the computer's request for confirmation is unlikely to catch the error; the user is confirming the action, not the file name. Thus asking for confirmation is unlikely to catch all slips." [4] http://www.asktog.com/columns/069ScottAdamsMeltdown.html, "Error Four: Confirmation Substituted for Undo" section: "For some bizarre reason, we seem to have settled on always, always, always giving users undo for such critical operations as deleting a single character. When users delete an entire document, however, we offer no possible recovery. That, in the real world, would be evidence of insanity." -- Neil Drumm http://delocalizedham.com/