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