I totally follow you. The "new" way really is the only sane way - and the way things have been for quite some time (thank god for Drupal sanity). But I thought you were talking about a NEW "new" way - that was inherently tied to CCK in some way. Thanks for the long version - preaching to the choir in my case - but certainly of use to anyone that hasn't had the pleasure of doing things the "new" way. andre Morbus Iff wrote:
So - excuse my ignorance - what is the difference between writing a module that does exactly what you say (i.e. packages logic that helps a magic field of some sort that could be used with any type of node) - via node form altering and the forms api?
Ignore CCK and Flexinode or what Drupal 5.x does.
Consider, for a moment, a module that oh, I dunno, allows you to define your emotion when you're writing something. After the user has Written Something, they can say they were Happy, Angry, or Sad.
Now, for the purposes of this thread, the "old" way is:
* a brand new node type that includes Title, Body, and Emotion. * you use hook_update, hook_insert, hook_form, etc., etc., to define a new node type called "Emotional Story".
With the above added to Drupal, we now have the core/default Story node type with Title and Body, and a new Emotional Story, with Title, Body, and Emotion. To add an emotion, you MUST use this new Emotional Story node type you've created. It has no correlation with other node types.
Following so far? It doesn't matter what you do with the Emotion field. You could program some logic in to get all Emotional Stories that were Sad, or to delay publication of Angry Emotional Stories until the next morning, when you have a chance to reread them a little calmer. This is what makes your module cool: not only by having this great Emotion field, but also Doing Something with it.
Now, for the purposes of this thread, the "new" way is:
* in admin/settings/modulename, show a list of all node types. * allow the user to choose which node types the module applies. * using hook_nodeapi to add your Emotion field to those node tyspe.
This is quite a different design. Instead of enforcing your own Emotional Story node type, you're now allowing the user to pick which node types they want your Emotion field to be applied to. With 4.7 or 5.x, they could say "you know, I want Emotions to apply to both Story AND Page". Then, when they create a Story or Page, they see the provided Title and Body by core, but also your Emotion field, as inserted via a hook_form_alter. Your data is saved via hook_nodeapi 'insert' or 'update', assigned to the node with 'load', deleted with 'delete', etc. You'd still continue to provide all the same logic as above (with Pages and Stories with "Angry" Emotion being delayed until tomorrow, Pages or Stories with "Sad" being viewable at a custom URL, etc.). You're just going about it a slightly different, but far more flexible, way.
Now, consider if every module started doing things this way. I can name three off the top of my head that do: Event, Case Tracker, and Organic Groups. Consider the following:
* I start off with a default Page node type provided by core. * I value-add the Event module to it - now Pages are also Events. * I value-add the Case Tracker module - now they're also Cases.
With a few mouseclicks, I have taken a default core type (Page, though it could also have been any other node type, or one created by CCK, etc.) and increased its capacity two fold: it is now a Case and gets all the logic (and fields) of Case Tracker, but is also an Event and gets Start/End times, and shows up in the calendar and is filterable with Event's dropdown filter. Adding Event Repeat, a plugin to Event, isn't a problem either - now Page is a Event Repeat(ing) Event that is also a Page that is also a Case. Later on, I install your module, choose that I want "Emotion" to apply to Page, and now have a Page that is an Event Repeating Event, a Case, and Emotional.
You can't do this under the "old" way, because the user is stuck using only your Emotional Story node type. Sure, "new" way modules could be used to expand upon Emotional Story (making them also an Event and also a Case Tracker Case), but when the flexibility exists to add fields + logic to /any/ node type, as opposed to shipping one, you should use it. It's quite rude to think that I have to use just YOUR node type when all 900 of my other nodes are "Story", and now I have to abandon them and use "Emotional Story" instead.
This is the heart of what Jaza was getting to, and why it showed up in a discussion upon hook_nodeapi(), which is the central Drupal hook that allows us to pull all this off.