Hi all. I just read a really excellent article by Aza Raskin: http://www.alistapart.com/articles/neveruseawarning which recommends, instead of those defacto "Are you sure you want to delete this?" warnings, just performing an undo-able deletion—or even better, moving the item to a "trash". This way the work flow is not interrupted, and there's no more just clicking "yes" out of habit, only to realise you made a horrible mistake.
I put in some obvious keywords for this at the Bakery and didn't find anything, so I thought I might write something like this myself. I figure in the DB it should look like this: any object that is "Trashable" has a "trashed" field of type DATETIME, default NULL, which is set to NOW() when it's trashed. A cron script runs every day (or maybe just whenever the next thing is trashed) and *actually* deletes any records where "trashed" < NOW() minus 30 days, say. It seems simple enough and I know I want all this logic to be abstracted from any one controller or model somehow, but after re- reading the Cookbook on components and behaviours, I'm still not sure which it should be. Here's how it would look from the user's POV, on, say, a blog: /posts/trash/15 - move ID#15 to trash /posts/prune_trash - maybe called automatically every day /posts/view_trash - to select a post to restore /posts/restore/15 So I'm thinking the posts model would "actAs Trashable", thus giving it the methods trash(), restore(), and prune_trash(), which the controller could have wrapper actions for. But it doesn't make sense for each controller to have to implement these from the ground up (or does it?), because any trashable model will have an 'id' field and a 'trashed' field, and that's all you need to know to perform these actions. I read another thread about creating generic controllers, so e.g. PostsController would extend TrashableController (which contains these wrapper actions) which would extend AppController. Because maybe not every object needs to be trashable. However, clearly some things do need to be specific to each controller -- e.g. the view to go with the view_trash action. So I'm just wondering if this sounds like the best way to approach it. CakePHP doesn't seem to provide an easy way (at least not AS easy) to have another level of inheritance between AppController and the real, individual controllers, so I thought maybe this is somehow going against its philosophy. Should this really be a plugin instead, or something? Thanks for any opinions you have, silverquick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
