Tim Lucas wrote:If you have a custom type which references other objects this delete code won't help you.
Overriding your custom types delete method won't do anything, because it's the referenced object's delete method that gets called.
The fact that this is dmHTML specific code in dmHTML's supertype should have set off alarm bells...
Maybe there needs to be a notification sent to all types when any object gets deleted? Either this, or some system level reference tracking (I vote for the former).
You are right of course :) How would you propose doing the former?
How about a callback mechanism, where each custom type has their static contentObjectWillBeDeleted(object) function invoked when an object is going to deleted.
Not sure whether its better before or after the delete (hasBeenDeleted or willBeDeleted). If you're only passing the objectid then you'd need it before in case your logic needs the data. If you passing the object instance itself then it probably doesn't make any difference.
The same method that does the deletion would also need to make the other calls so we can wrap them up in a <cftransaction> (I think that's the case with cftransaction isn't it?)
For a simple implementation we could modify types.cfc:
= Add an empty contentObjectWillBeDeleted function = Change delete method to have: - start transaction - call copai to get list of types - call objectWillBeDeleted() on each type - delete object from store - end transaction
Normally the data store or something else would have the responsibility of notifying the types, rather than a type itself...
If we're just talking about casual deletion of objects then unless its slow or it adds something else then there's probably no need to have the custom type specify the types it wants to receives notifications for (Observer pattern like).
- tim
--- You are currently subscribed to farcry-dev as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
