[development] No module-defined node types?

[Andre Molnar]

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.
>