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(a)viapositiva.net>
>Subject: RE: RE: RE: [development] changes to hook_nodeapi
>To: <development(a)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
Well, the bad thing about wrapper functions is that people won't
change them if it is not necessary. If we take the wrapper function
out after the next release, we will face the same problem.
2006/8/31, John VanDyk <jvandyk(a)iastate.edu>:
> From http://drupal.org/node/64279#module-exists :
>
> "module_exist() is now module_exists()
> For consistency with PHP function_exists, file_exists, etc. That's
> about all there is to say about that. :)"
>
> From my local copy of cvs:
>
> $ cd /cvs/contributions/modules
> $ grep -r module_exist\( . | wc -l
> 630
>
> It would be nice to have a wrapper function in for one release cycle.
>
