That's exactly how I do this. I'm not a huge fan of ActiveRecord or patterns where objects know how to save themselves, but I've found that the flexibility outweighs the cons. If you have a generic delete() method in your base Decorator, then you can extend it with a SoftDeleteAwareDecorator, which overrides the delete() method and instead does a save() and updates the deleted flag instead of deleting it. Then any concrete Decorators extend the soft delete Decorator, and nothing external has to know whether the record is actually deleted or soft deleted.
On Tue, Mar 3, 2009 at 11:23 AM, Nando <d.na...@gmail.com> wrote: > > Rob, > > I use soft deletes all the time in Transfer. In essence, it's simply > an update to a particular column. > > My understanding from what Mark has said in the past is that because > everyone does soft deletes in a different way, in fact your way, > involving a date field, is different from mine, so it's somewhat > difficult to implement in Transfer in a way that would work well for > everyone. > > I know Brian Kotek is a big fan of injecting transfer into his > decorators, precisely into an abstract decorator, wrapping transfer > methods to enable stuff like myObject.save(). If you adopted that > approach, you could overwrite the abstract decorator on the concrete > to enable your approach to soft deletes, even a varying approach as > you've described, and it would be nicely abstracted away so that > everywhere in your app you'd call myObject.delete(). > > I haven't done that in my current app, but I have it mind for next time. > > Nando > > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins > <robert.rawl...@thinkbluemedia.co.uk> wrote: > > > > Hi John, thanks. > > > > Yeah the way I see its implementation working would be to keep the > > delete method invoketion the same, just change its implementation > > dependant on the XML configuration, this would allow some objects to > > be properly deleted and other only soft deleted likewise with > > cascading the deletes, sometimes I'll want a parent object to be soft > > deleted but its children are not audited so they can be properly > > removed :-) > > > > I kind of remember someone mentioning it was on the roadmap when I > > last asked a few months back, perhaps I'll play around with some > > patches and suggestions for Mark and see if I cant accelerate it a > > little. > > > > Rob > > > > On Mar 3, 4:01 pm, John Whish <john.wh...@googlemail.com> wrote: > >> I believe that soft delete is already on the road map. I haven't tried > it, > >> but you should be able to overwrite the Transfer save method to do an > update > >> instead of a delete. So you code would still call the delete method. > > > > > > > > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > na...@carbonzero.ch > > > > --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
