re: RE: RE: [development] changes to hook_nodeapi
Jeff, it seems to me you are saying that this patch needs a patch to restore the functionality present in 4.7...
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.
The hooks into Forms API are not easy to grasp the logic of, even after spending many hours on this. 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). -Peter
Date: Thu, 31 Aug 2006 11:20:16 -0500 From: "Jeff Eaton" <jeff@viapositiva.net> Subject: RE: RE: [development] changes to hook_nodeapi To: <development@drupal.org> Message-ID: <002501c6cd19$5c208770$6700a8c0@JEATON2DEV> ...
As of this patch, hook_nodapi no longer gets called, for example, with $op='update".
Well... Yes. That was what the patch did. It changed the system to use form processing hooks for CRUD interaction. It can definitely be said that there should be an easier way to 'tie in' to those operations. A specific helper function rather than form_alter, for example.
--Jeff
Ok, just so that I can judge my sanity here. We are removing, arguably unnecessarily, a simple easy to grasp system for dealing with crud operations and replacing it with a, as demonstrated by messages from other developers, harder to grasp system that will require additional lines of code to accomplish things I can already do with 4.7. We do this all with no gain in features or performance in return? I must have missed something. I think I need a cocktail…. Anyone?
On Thu, 2006-08-31 at 15:45 -0400, Andrew Lee wrote:
Ok, just so that I can judge my sanity here. We are removing, arguably unnecessarily, a simple easy to grasp system for dealing with crud operations and replacing it with a, as demonstrated by messages from other developers, harder to grasp system that will require additional lines of code to accomplish things I can already do with 4.7. We do this all with no gain in features or performance in return? I must have missed something. I think I need a cocktail…. Anyone?
Actually in my experience formAPI is a much easier to grasp concept. The fact that we haven't completely migrated our model to it makes it confusing some days. Over all I have a quicker view of WTF?!?!? if I print_r($form) from somewhere I can see everything that will be called and what order it will be called in while processing the structure. I fully agree with submit and validate being moved into the model.... if 'update' is deprecated I have problem. We already have a partial rendering solution resting on formAPI and a pretty complete form processing solution built on formAPI. I'd like to see those to projects reach completion before we start handing the data layer over to formAPI. .darrel. ps. don't get confused by the names. formAPI has very little to do with forms... it is more like a rendering or processing pipeline.
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
On 31 Aug 2006, at 10:01 PM, Jeff Eaton wrote:
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?
I've mentioned this before, but hooks are also callbacks, you could make the node form register them automatically. ie: if (function_exists($node->type . '_validate')) { $form['#validate][$node->type . '_validate'] = array(); } foreach (module_implements('nodeapi') as $module) { $form['#validate'][$module . '_nodeapi'] = array('validate'); } that would remove all unneccesary form alters, but would require the function definition of node api to change.
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).
in 4.7 programmatic nodes cannot be validated properly. for 4.8/5.0, thats now fixed. with 4.9/5.1, we will likely improve the data model as you are suggesting. please participate in adrians fapi 3 discussion starting in brussels. this is a long road, and some things smell along the way. i agree that some use cases are less convenient in 4.8/5.0. but at least those can be worked around with a little learning. ideas for simplifying fapi and making it learn easier are always welcome.
participants (6)
-
adrian rossouw -
Andrew Lee -
Darrel O'Pry -
Jeff Eaton -
Moshe Weitzman -
Peter Wolanin