Brian, I seem to remember that you've implemented an abstract decorator in such a way that your transfer objects know how to save and delete themselves. Is that correct? If so, then this is an excellent example of where that architectural decision pays off nicely.
Nando On Wed, Jan 28, 2009 at 2:50 PM, Brian Kotek <[email protected]> wrote: > I just override my default delete() method within objects that require soft > deletes, which triggers an update instead to set the deleted flag to true > and ensures that the object is purged from the cache. It seems to work > pretty well since nothing outside the object knows that calling delete() on > it is actually doing a soft delete. > > On Wed, Jan 28, 2009 at 8:07 AM, Nando <[email protected]> wrote: >> >> I don't find that small snippet of code difficult to read, but that's just >> me. It could be encapsulated in a doSoftDelete controller method for >> clarity, or in your decorator if you're going that route already. >> >> But to be clear, I DO get confused reading code blocks sometimes, even my >> own, but especially other's code sometimes confuses the heck out of me! ;-) > > > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
