changes to hook_nodeapi
Dear developers, A patch was recently committed: http://drupal.org/node/68418 that moves the insert/update/delete operations out of hook_nodeapi. While I realize this was reviewed by a number of more experienced people, I would still like to voice an objection. After trying to use the API after this patch, I think it was not a good idea. I can't see how it improves programmatic submission of nodes- after trying it last night it seems to make it harder. It was argued that this would make the node update/insert/delete process mroe efficienct since only the registered submit sitems in the form are called rather than hook_nodeapi() for all modules. However, I think an approach that would be similer, but much more consistent with the current API, simpler in terms of updating contrib modules, and essentially the same in terms of reducing the # of fucntion calls would be breaking of hook_nodeapi into a series of hooks like hook_nodeapi_view(), hook_nodeapi_load(), hook_nodeapi_update(). This would probably add much more in terms of efficiency than this patch since there are typically many more load, view, etc. operations than update/insert/delete. -Peter
I agree completely. This patch is a bad idea. The idea of removing functionality to force programmers to use a certain convention is not a good one. Forcing developers to use hook_form_alter to perform these operations is taking away functionality. If we look at Drupal as more than an API, more than a content management system, as an application builder; this patch makes no sense. I have several web applications that perform operations based on a node just being accessed. I would need to jump through hoops to make this work with this patch, having to fake a form submit just to call the required code. IMHO, this moves Drupal in the entirely wrong direction. This could seriously end my love affair with Drupal. Please reconsider! I want to reiterate what jvandyk <http://drupal.org/user/2375> said about the patch, "No. This is a bad idea. The hooks being removed are at the data level, and are being replaced at the form submission level. What this means is that if you want to work with nodes programmatically you'll have to fake a form submission, which is a big pain. Remember, through the web browser is only one way to create content. Content could also be created by XML-RPC calls, by wrapping a legacy database, by periodic file import, etc. When you call node_save, data-related things like nodeapi insert happen. These are not form-related. They're data-related. This patch makes Drupal less flexible. I also think it's premature to be thinking about this. After fapi 2.0 hits, we should think about it." Andrew Lee INTRAMEDIA.NET, inc
I haven't had a chance to look at the details of the nodeapi patch in question, but I will say that programmatic submission of data using forms just got a bit simpler, as http://drupal.org/node/80470 was committed. It adds a 'drupal_execute()' function that processes forms without any of the rendering/ui cruft. changing a node, for example, would involve the following: $node - node_load(1); $values['title'] = 'My new title!'; drupal_execute($node->type . '_node_form', $values, $node); It's different, yes. But the advantage is that you will get all of the validation logic, all of the modifications made by form_alter code (like taxonomy_defaults), and so on, for free. I can't offer any insight into the actual nodeapi changes, but hopefully the above snippet helps assuage some fears about programmatic content changes.
Andrew Lee wrote:
I want to reiterate what jvandyk <http://drupal.org/user/2375> said about the patch, "No. This is a bad idea. The hooks being removed are at the data level, and are being replaced at the form submission level. What this means is that if you want to work with nodes programmatically you'll have to fake a form submission, which is a big pain. Remember, through the web browser is only one way to create content. Content could also be created by XML-RPC calls, by wrapping a legacy database, by periodic file import, etc.
When you call node_save, data-related things like nodeapi insert happen. These are not form-related. They're data-related.
This patch makes Drupal less flexible. I also think it's premature to be thinking about this. After fapi 2.0 hits, we should think about it."
I'd have to say I agree with John VanDyk on this point. This muddies Drupal's architecture, rather than improves it.
participants (4)
-
Andrew Lee -
Chris Johnson -
Jeff Eaton -
Peter Wolanin