re: RE: [development] changes to hook_nodeapi
My issue isn't that programmatic submission needed to be easier, but rather the API for acting on the creation, etc. of nodes. Just got less consistent and harder to use. As of this patch, hook_nodapi no longer gets called, for example, with $op='update". -Peter
Date: Thu, 31 Aug 2006 10:46:18 -0500 From: "Jeff Eaton" <jeff@viapositiva.net> Subject: RE: [development] changes to hook_nodeapi To: <development@drupal.org> Message-ID: <000f01c6cd14$9d436ec0$6700a8c0@JEATON2DEV> Content-Type: text/plain; charset="us-ascii"
I haven't had a chance to look at the details of the nodeapi patch in question, but I will say that programmatic submission of data using forms just got a bit simpler, as http://drupal.org/node/80470 was committed. It adds a 'drupal_execute()' function that processes forms without any of the rendering/ui cruft.
My issue isn't that programmatic submission needed to be easier, but rather the API for acting on the creation, etc. of nodes. Just got less consistent and harder to use.
Fair enough. Someone else had just commented that programmatic submission was hard, or complex, and made worse by the patch.
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
This just feels super hacky to me. When I am doing things programmatically with a node, I don't necessarily want form validation to run. It may very well screw me up. Often times I don't want to closely couple my node and its operations with a form. It's not that this isn't possible with this patch; it's just makes a lot less sense. The other issue I have here is module compatibility. The Drupal philosophy is to the keep the core as compact as possible, and provide additional functionality in modules. A noble plan, indeed. This puts a lot of the value of Drupal in the modules. When we radically change the API and create a nightmare for module developers to bring their code up to compliance, we end up eliminating many modules and devaluing the Drupal product overall. Why take these operations out of hook_nodeapi if we don't need to? Is this strictly a performance concern? How can it be with huge sites running Drupal with no problems. If it's a performance issue, then I volunteer to find a solution without eliminating these operations from hook_nodeapi. Pure developers will say that this is how we strictly enforce coding standards and provide a better product. This doesn't work for the sys-admin running Drupal 4.6 on 20 sites and wants to upgrade to the latest and greatest but can't because of module compatibility hell. There needs to be a balance. Stepping off high horse now. -Andrew
Andrew Lee wrote:
This just feels super hacky to me. When I am doing things programmatically with a node, I don't necessarily want form validation to run. It may very well screw me up. Often times I don't want to closely couple my node and its operations with a form. It's not that this isn't possible with this patch; it's just makes a lot less sense.
Unless it is for development purposes, I cannot imagine why my programmatically created nodes shouldn't be validated as any other nodes.
The other issue I have here is module compatibility. The Drupal philosophy is to the keep the core as compact as possible, and provide additional functionality in modules. A noble plan, indeed. This puts a lot of the value of Drupal in the modules. When we radically change the API and create a nightmare for module developers to bring their code up to compliance, we end up eliminating many modules and devaluing the Drupal product overall. Why
Please stop right here. Read http://buytaert.net/the-pain-before-the-payoff Cheers, Gerhard
On 8/31/06, *Gerhard Killesreiter* <gerhard@killesreiter.de> wrote:
Unless it is for development purposes, I cannot imagine why my programmatically created nodes shouldn't be validated as any other nodes.
I'll give you one of many examples I have. Every morning a web based application I created and manage imports a large fixed length flat file from a legacy mainframe system. The mainframe app that generates this data is fed by people typing into un-validated form fields on terminals. My application needs to know about this data as soon as it shows up because it tracks a variety of metrics that are date sensitive. The data import routines clean up "nodes" as they come in externally and try to intelligently correct them for a variety of missing or incomplete elements. There is a level at which an imported "node" will be discarded because it just lacks too much information. The data is then inserted into the web app. For the most part this data would pass through the, now irrelevant, form validation routine. But not always, we let data in from the import that is missing elements that a user would be required to enter if they were typing data into the web app directly. We force users to enter this info, but can't force it from the mainframe. But, we can't throw this node out because we need to track it and know that the next day the missing info will most likely be included in the export file. In our application the data object are completely separate from the form elements, and in many cases we have multiple forms that talk to a data object with different validation rules. This is, admittedly, an obscure example. But there are countless scenarios like this. This particular app is not built in Drupal, but I would like to think that it could be.
Please stop right here. Read http://buytaert.net/the-pain-before-the-payoff
Yes, I have ready this and I agree with it in the context of 4.6-4.7. That said, if we keep radically changing the Drupal API for every release without serious considerations for backwards compatibility there will never be a pay-off, only pain. Your community will start dreaming of Plone or Rails. Think of it like this, when PHP 5 came out with all the enhancements to object oriented programming, they didn't eliminate people ability to program in a top down fashion. That would certainly have been unnecessary and broken Drupal. Ok, I won't go any further with this on this thread is it is off topic. -Andrew
I'll give you one of many examples I have. Every morning a web based application I created and manage imports a large fixed length flat file from a legacy mainframe system. The mainframe app that generates this data is fed by people typing into un-validated form fields on terminals. My application needs to know about this data as soon as it shows up because it tracks a variety of metrics that are date sensitive. The data import routines clean up "nodes" as they come in externally and try to intelligently correct them for a variety of missing or incomplete elements. There is a level at which an imported "node" will be discarded because it just lacks too much information. The data is then inserted into the web app. For the most part this data would pass through the, now irrelevant, form validation routine. But not always, we let data in from the import that is missing elements that a user would be required to enter if they were typing data into the web app directly. We force users to enter this info, but can't force it from the mainframe. But, we can't throw this node out because we need to track it and know that the next day the missing info will most likely be included in the export file. In our application the data object are completely separate from the form elements, and in many cases we have multiple forms that talk to a data object with different validation rules.
to get rid of a given validation like taxonomy (for example), you just do unset($form[#validate][taxonomy_node_validate]). to get all of validators, use unset($form[#validate]). your custom cleanup routine could run outside of drupal framework on the file but it could run within drupal too. just add your own #validate handler and then process the form. thanks for the example. keep them coming! until we hear of a something significant that can't be done with the new system, i'm chalking up the complaints to unfamiliarity.
On Thu, 2006-08-31 at 11:20 -0500, Jeff Eaton wrote:
My issue isn't that programmatic submission needed to be easier, but rather the API for acting on the creation, etc. of nodes. Just got less consistent and harder to use.
Fair enough. Someone else had just commented that programmatic submission was hard, or complex, and made worse by the patch.
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
Form processing operations should call crud functions... I'm all about submit and validate being pulled from nodeapi, since those are in a way for level... but I think the crud itself should stay in nodeapi.
Precisely, by keeping crud at the data object level, aki nodeapi, we have a better chance of decoupling the form level. Is there any reason that a module should not be able to implement different form interfaces to the same node object? Most applications do this in one way or the other.
On 31 Aug 2006, at 9:00 PM, Andrew Lee wrote:
Precisely, by keeping crud at the data object level, aki nodeapi, we have a better chance of decoupling the form level. Is there any reason that a module should not be able to implement different form interfaces to the same node object? Most applications do this in one way or the other.
The issue is that FAPI (it really shouldn't be called that), muddles the data structures for the view and model components of the MVC structure. You _do_ have a data model in the form, but we need a function like form_builder to extract it. I will be discussing at DrupalCon how to untangle these two concerns, and how it ties into CRUD. (every 'type' with a model, automatically gets a form 'scaffolding' it.)
Peter Wolanin wrote:
My issue isn't that programmatic submission needed to be easier, but rather the API for acting on the creation, etc. of nodes. Just got less consistent and harder to use.
please elaborate on 'harder to use'. there might be an unforeseen consequence of the patch, but we can't understand the issue and take action until you tell us exactly whats wrong/difficult. the recommended way to take action is now to register submit handlers. thats consistent with all the other forms in drupal. also, this isn't a performance patch. i still owe documentation for this change and an explanation on this list. i'm hoping that some docs will help everyone feel more comfortable in the new system.
participants (7)
-
adrian rossouw -
Andrew Lee -
Darrel O'Pry -
Gerhard Killesreiter -
Jeff Eaton -
Moshe Weitzman -
Peter Wolanin