(Originally written by Morbus on the Drupal consulting mailing list)

"I've just been re-reading your notes and your design seems very elegant. If you don't mind me asking, what do you mean by 'making a CCK project type an Organic Group'?

Allow a long-winded explanation, most explanatory pre-history.

First off, I always future proof my installations. To "future proof" generally means "I am currently an idiot. I can not see what I will need five years from now. Therefore, I should make the most flexible decision RIGHT NOW, even though I don't know if I'll ever use it."

Consider, today, that the only thing you need for a project is the title ("Client A") and a body ("Client A rules!"). Since you only need these two things RIGHT NOW, you may say "well, hell, a regular old Drupal 'page' could be a Case Tracker project because it does everything!" You then go ahead and, over the course of 4 years, make 300 projects - that is, 300 'page' node type that are Case Tracker projects.

But, coming around on 5 years from now, you decide, "you know, it'd really be useful if I included some contact information on each of these projects, because I'm getting quite confused on who the contact person is, or what their website was." But, because you chose Drupal's 'page' node type, you don't have this capability - 'page' ONLY has title and body, and you can't add anything more to it [1]. Suddenly, you have to decide if a) you want to write an upgrader/converter for all 300 'page' node types or b) if you can live without the feature.

Thus, for everything I do, I always start out with CCK. Today, right now, I may create a custom CCK node type called 'monkey'. It will contain only the title and body that I need today. But, if five years from now I want to add some URL fields, I can - because it's a CCK node type, and that's what CCK node types are designed for: customizing.

So, that's why I start with CCK.

Now, a lot of Drupal modules allow you to "value add" (consultant-speak here) to existing node types. For instance, Organic Groups allows you to either a) use their existing "og" node type, which has the same problems described above - an inability to modify the fields five years from now, or b) "value add" to an existing node type, which allows Organic Groups to add its own features and fields to a node type of your choice. Lots of modules do this - event.module provides it own basic node type or can value add one of your own creation and, now, so does Case Tracker (for both projects and cases).

So, with the 'monkey' CCK node type I created in my awesome example, I can say to Organic Groups: "you know, instead of using your provided node type, I want you to use my 'monkey' type instead." This will cause Organic Groups to treat 'monkey' nodes as its own - it will add some Group related fields such as "Subscription options" and so forth. This is "value adding" to an existing node type, in this case, 'monkey'.

But, you don't need to stop there. We've got our CCK node type 'monkey' (CCK to future proof it for us), and we've made it an Organic Group (so as to get all the OG features). We can also have Case Tracker treat a 'monkey' node type as a Case Tracker project - now 'monkey' is both a CCK node type (infinitely flexible), an Organic Group (with subscription options and other OG features), AND a Case Tracker project. All three modules will take this lowly 'monkey' and make it better.

Thus, our 'monkey' node type:

allows new fields to be added to it (CCK),
is an Organic Group with subscription options (OG),
is a Case Tracker project that cases can be assigned to.

These combine to create the following previously unavailable feature:

* cases assigned to a project can only be viewed by subscribers. This happens because OG's node visibility controls what appears whenever you create a node assigned to a particular Group (which is what'd happen when you create a Case Tracker case assigned to a particular project which, as we've established earlier, is also an Organic Group).

Maybe I should make a diagram of all this? ;)

/How/ you do this configuration is via the settings - under both admin/settings/og and admin/settings/casetracker, you tell the modules which node types you want them to value add. Some modules have this actual configuration in a different location (such as event.module).

The above design can be applied to other node types, as I've mentioned. I am testing "milestone" equivalents via a custom CCK node type (for that flexibility), assigned as an event (for the date options), and a Case Tracker case (for the priority/assigned to/state) options. This allows this case to be part of a project (with all the OG visibility goodness), but also to be shown in a calendar (with all the event.module goodness, like iCal export and other modules that themselves value-add to event.module, like rsvp).

I hoped I explained that well.

[1] Ignore, for the sake of my future proofing argument, that Drupal 5.0 WILL allow you to modify the 'page' node type.

Comments

Anonymous’s picture

Coming from a product and developing background, this authors point is valid. However, it is important to NOT underestimate the effect of good planning from the beginning of any large-scale Drupal deployment.

Perhaps in 5 months, you have over 200 nodes, and you wish to create some new fields or taxonomy. The time that would have been saved by performing a through requirements analysis would be insane. Then you also wouldn't have to enter values for these fields manually.

Again, basic software principals... The more time you spend planning, the less time later to develop and far less time fixing inconsistencies and logical errors.

Diegen’s picture

Hehe very nice AND helpful in explaining the WHY.

Tks.