On 18 Aug 2005, at 4:48 PM, Todd Grimason wrote:
Sorry if this isn't the right etiquette - I have a question(s) about this issue which didn't seem right to clutter up the "official" issue comments with:
Why is node_save() called before the insert/update event fires (called via nodeapi) and not after? It seems a bit arbitrary.
I guess there are situations where you don't want to fire that until the node is saved, but that would seem to preclude anything else from modifying that node without having to save it again. Was this a decision to be a bit more simple and accept the requirement of other modules having to re-save if they want to modify the node itself, and not just affect other things?
Maybe what's needed is this: http://api.rubyonrails.com/classes/ActiveRecord/Callbacks.html
Well I'm sorta joking, but the key thing here is as far as I can see (not very, I'm fairly new to the deep internals of drupal) is having a distinction between pre- and post-save [aka insert/update], since "on save" is ambigious isn't it? (well in name at least, the actual behavior in this case it appears to actually be a "post save" event, right?).
I think that this is a very good point. I ran into something similar to this while working on HTML export for books - here the nodes were part of a tree, and children needed to be processed in the course of processing a node. In my situation, I implemented a function to traverse the structure - it accepts callbacks called at the start of a node visit and and the end. I think a similar approach would work for other structures. The problem of having nodes tracking how often they are visited is that the node can't (shouldn't) know about any context or global structure it appears in. So, I agree with Dries - having to save this kind of state in a node is an indication that something is wrong with the design.
Until I followed all the calls around, I assumed the callbacks had a chance to run before node->save was actually called -- like everyone gets to do their thing before the node is stored away in the DB -- but now I see you actually gotta use your copy and stick it in the database yourself, basically overwriting the core functionality -- so potentially you could have 0..* saves in response to the insert/update callback, yes?
Am I anywhere near understanding what's going on here?
--
________________________________ toddgrimason*todd[ at ]slack.net
puregin http://www.puregin.org