[development] hook_nodeapi()

[Rob Barreca]

>
> 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 at 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?rev=1.4&view=log 
>> but not sure how far along it is.
>>
>> Rob Roy Barreca
>> Founder and COO
>> Electronic Insight Corporation
>> http://www.electronicinsight.com
>> rob at 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. 
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070103/841c78e9/attachment.htm