re: RE: RE: RE: [development] changes to hook_nodeapi
Jeff, My criticism was a little too broad, perhaps- I don't think the entire patch should be rolled back but that at the least 3 of the 4 ops, insert, update, delete, should stay where they are in hook_nodeapi. I might also argue for the return of hook_delete. The removal of hook_validate, hook_insert, and hook_update make more sense, becuase a module that implements them would already have to be constructing a node form. However, that still means that calling node_save() in its present form wouldn't work. I agree with your comment that node_save should be refactored as a helper function (regardless). I don't think this patch fundamentally enables programatic submission (correct me if I'm wrong) -that was in other patches. http://drupal.org/node/68418 does make *some* changes to assist programtic submission, but primarily eliminates various hooks from the node module and removes ops from hook_nodeapi. -Peter
Date: Thu, 31 Aug 2006 15:01:39 -0500 From: "Jeff Eaton" <jeff@viapositiva.net> Subject: RE: RE: RE: [development] changes to hook_nodeapi To: <development@drupal.org> Message-ID: <003e01c6cd38$4900a700$6700a8c0@JEATON2DEV> ...
Perhaps what we should ask is, 'OTHER than rolling back an important piece of code recapturing, how can we make the new mechanism as easy for developers as the old one was?' Not _the same as_ but _as easy as_. Perhaps a helper function to 'register' your module's CRUD without altering any form arrays? Perhaps node_save() existing as a wrapper function for the functionality?
Even without this patch, any developer who *wants* to use the Forms API and submit hooks can. This patch *forces* us, even when it's not appropriate to the data model (as mentioned in a previous post).
No. Previously, developers who wanted to use the Form API hooks for programmatic submission could not. It didn't work. Period. That was sad, because the provisions for validation, error handling, and extendibility that are there in Forms API are all lacking in nodeapi's simple model.
What is needed, IMO, is a set of simpler wrappers and interfaces for the 'simple' cases that don't cripple the complex ones. Previously, the simple cases just used a completely different validation/submission pipeline -- and that was a serious problem.
We now have a different (albeit less fundamental) problem -- but one that is solvable. IMO, at least :)
--Jeff
On 31 Aug 2006, at 23:58, Peter Wolanin wrote:
My criticism was a little too broad, perhaps- I don't think the entire patch should be rolled back but that at the least 3 of the 4 ops, insert, update, delete, should stay where they are in hook_nodeapi. I might also argue for the return of hook_delete.
I just rolled back the patch. Programmatic submissions are still possible but the old _nodeapi hook is back. This give us more time to think about it, and to figure out a solution that more people are comfortable with. No need to rush this. :) -- Dries Buytaert :: http://www.buytaert.net/
On 31 Aug 2006, at 23:58, Peter Wolanin wrote:
My criticism was a little too broad, perhaps- I don't think the entire patch should be rolled back but that at the least 3 of the 4 ops, insert, update, delete, should stay where they are in hook_nodeapi. I might also argue for the return of hook_delete.
I just rolled back the patch. Programmatic submissions are still possible but the old _nodeapi hook is back. This give us more time to think about it, and to figure out a solution that more people are comfortable with. No need to rush this. :)
Thank you Dries, this is the least painful path, specially the freeze is practically upon us. Perhaps when Moshe comes up with a good description, this would be cleared up, but until then, the CRUD functions in nodeapi are crucial for modules to act on node events. I also remember someone mentioning discrete CRUD functions outside of nodeapi a while back (was it webchick?)
On Thursday 31 August 2006 19:55, Khalid B wrote:
I just rolled back the patch. Programmatic submissions are still possible but the old _nodeapi hook is back. This give us more time to think about it, and to figure out a solution that more people are comfortable with. No need to rush this. :)
Thank you Dries, this is the least painful path, specially the freeze is practically upon us.
Perhaps when Moshe comes up with a good description, this would be cleared up, but until then, the CRUD functions in nodeapi are crucial for modules to act on node events.
I also remember someone mentioning discrete CRUD functions outside of nodeapi a while back (was it webchick?)
I think you're looking for this thread: http://drupal.org/node/79684 I did find it odd that there was a patch to remove independent CRUD functions from core at the same time that there was a thread to add a complete CRUD API for all major Drupal entities. My own take on the matter is that direct-CRUD (node_load(); $node->foo = 'bar'; node_save();) and form automation (FAPI) both have very legitimate uses. Especially as Drupal is far more than just a form handling CMS but a full-on development API in many ways, the ability to do things without going through a virtual form is very important. Don't get me wrong; programmatic submission of form as now possible with the pull-based FAPI is great. But it addresses a different set of problems than direct CRUD functions. They serve two different purposes. They probably can, and if so should, share a lot of the same backend code, but they're different APIs because they serve two different but both legitimate programming needs. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
participants (4)
-
Dries Buytaert -
Khalid B -
Larry Garfield -
Peter Wolanin