We shouldn't head towards eliminating the default node hooks. They're really useful, and simple interfaces for building good content types. We shouldn't drop good, reliable, and simple because we've added super flexible on top.
That makes sense, but I do feel that once we get to a point where we have a solid hook ordering (chx just started a thread) that we shouldn't just keep hook_insert/update/delete because they are convenient should we? Why not clean those out and head towards a unified nodeapi hook where you could act on *any* node type and register a super low weight/order/first when acting on on mymodule's node type? Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Darrel O'Pry wrote:
On Tue, 2007-01-02 at 17:03 -0800, Rob Barreca wrote:
All four of the module-defined node types that are still in 5.0 core (blog, book, forum, and poll) can and should be made history, and in their place we can just have hook_nodeapi() implementations
I definitely agree, but envision some module ordering/weighting issues that will need to be worked out as we begin to unify these since you lose the pre-nodeapi hooks and have everything going at the same "time". chx has done some prelim work on this at http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/chx/weights.php?r... but not sure how far along it is.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com
We shouldn't head towards eliminating the default node hooks. They're really useful, and simple interfaces for building good content types. We shouldn't drop good, reliable, and simple because we've added super flexible on top. The features aren't exclusive. I could even see CCK using node hooks for purely user defined content types, and nodeAPI for extended content types.
Some ordering problems can be overcome with the way the nodeAPI and node hooks currently work. I see the initial inclusion of custom fields in core as probably using a hook between the node hook invocation and nodeAPI invocation. Weights couldn't cleanly solve the ordering issues we have, especially where different API's implemented by the same module should be ran in different orders.