コンテンツ管理の変遷

Drupalの今後を占う上で役に立つかも知れないので、コンテンツ管理の部分でDrupalがこれまでどのように進化してきたかをまとめておきたいと思います。(筆者は4.6からしか使用していない為、4.6以降についてのみ記述します。また筆者の経験を元に記述しているため、偏見も多く含まれている事をご了承下さい。)

コンテンツ定義方法と表示カスタマイズ手段の変遷

Flexinode

Drupal4.6当時、独自のコンテンツタイプを使用する場合は、既存のモジュールをコピーして新たにモジュールを開発するか、またはFlexinodeというモジュールを使用していました。
このモジュールは、CCKの原型となったモジュールで、日付型やセレクトボックスなどのフィールドを追加し独自の入力フォームを作成出来る当時としては画期的なモジュールだったと思います。

CCKの登場

非常に便利だったFlexinodeですが、大きな欠点がありました。
それはデータベースのテーブル設計上の問題で

• 多くのコンテンツを取得/表示する場合は、パフォーマンスが低下する。
• より複雑なフィールド型を追加しずらい。

という点です。既に多くのサイトで使用されていたFlexinodeにおいて根本的な設計変更を行う事は困難だったため、それらの欠点を改善すべく、拡張性を持つ設計で、かつパフォーマンスの問題も改善した新たなモジュールCCKが開発されました。Drupal4.7当時は、使い慣れたFlexinodeがあるのにどうして同じようなモジュールが必要なのかという議論もありましたが、次第にその利点が認知されてゆきます。

CCKの一般化とフィールド定義モジュールの拡大

Drupal5.xでCCKの一部の機能がコア機能として取り込まれた事により、CCKがより一般的に認知され、CCKで追加可能なフィールドを定義する拡張モジュールが急速に増加しました。その影響により、これ以前は

1. 拡張モジュールを追加
2. 拡張モジュールの設定変更
3. 拡張モジュールの表示をカスタマイズ

として新たな機能を追加していたワークフローが、この頃からは、

1. CCKのフィールド定義モジュールを追加
2. CCKで新たなコンテンツタイプを定義
3. Viewsモジュールでコンテンツ表示またはブロック表示のビューを作成

という流れに変わってきます。これにより、Viewsモジュールの重要性、利便性がより広く知られるようになりました。

Views2の登場

Viewsの機能を発展させたViews2は、複数のコンテンツのリレーションを明示的に指定する事が可能になり、より複雑なデータ構造もプログラム開発なしで集約表示出来るようになりました。(開発者の方は、SQL文で複数テーブルのJOIN条件を指定出来るようになったと思えば理解しやすいと思います。)

フィールド管理機能がコアに

Drupal7.xではフィールド管理機能がコア機能(API)として取り込まれる事が決まっています。その結果、ユーザアカウントのようなノード以外の情報も自由にフィールドを拡張する事が可能になります。¹
またコア管理対象の最小単位がフィールドとなる為、CCKが一般化した時と同様にフィールド管理機能の拡張を目的とした拡張モジュールが多く開発される事になるかもしれません。
「すべてのコンテンツはノードである。」
という言い方をよくされるDrupalですが、7.x以降はノードだけが特別なオブジェクトではなくなりますので、
「すべてのDrupalオブジェクトはフィールドで構成される」
となるかも知れませんね。

¹6.x以前でもprofileモジュールによってユーザアカウントフィールドを拡張する事は可能ですが、profileモジュールもFlexinodeモジュール同様にDB設計上の問題を抱えています。

■参考にしたサイト一覧

• DrupalCon Boston 2008 - The State of Drupal (March 3, 2008)
• Looking Foward to Drupal 7 (Lullabot)
• Flexinode
• Content Construction Kit (CCK)
• Views