[development] changes to hook_nodeapi

[Jeff Eaton]

> it seems to me you are saying that this patch needs a patch 
> to restore the functionality present in 4.7...

No. This isn't about functionality: from that standpoint, 4.7 was
crippled and 4.8/5.0 is a huge leap forward. Why? In 4.7, the 'easy'
hooks were broken. They didn't work reliably, and people got around this
by writing their own one-off validation code on a per-module basis
whenever nodes were created -- or by simply ignoring validation
completely. We essentially had two different CRUD pipelines. Now, the
same CRUD pipeline can be used for validation and CRUD. Validation can
be turned off with a single line call: unset($form['#validate']); if you
really want to stick in bad data.

So the issue isn't functionality. The issue is how that functionality is
accessed, and how simple and/or straightforward it is. Which brings us
to your next point...


> >From my point of view as a relative newcomer to this, the present API
> for node handling is simple to grasp the logic of.  I think 
> this is a key point that is being overlooked- the barrier for 
> entry of new developers and rention of existing ones.  If I 
> call node_save() on a node object, but then my data is not 
> saved, that's not logical to me.

Node_save() should probably be a wrapper function for the new approach.
I haven't looked closely at it since the last patch landed. And you're
correct that dealing with the FormAPI for pure CRUD work is needlessly
complex. The problem, underneath it all, is that FormAPI as released in
4.7 was really three APIs: RenderAPI, FormAPI, and CrudAPI. Rendering
work is now being split out properly, as evidenced by the node_render()
code that went in. And we're slowly working towards a good separation of
the CRUD from the Forms.

So. Our problem here is the transitional period of complexity as the
refactoring happens. That's annoying and frustrating -- but also not the
cataclysmic issue some have made it out to be. It's not logical to
implement two incompatible CRUD pipelines, and leave one broken just
because it's what is familiar.

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