先月の16日に「Drupal 7 への対応に向けて」というエントリーを書いて以降、
　時間を作っては、鋭意、Druapl 7 への対応に取り組んできました。
　Drupal の技術体系は多岐に渡り、それなりに複雑であるために、
　演繹的にその変更点の全詳細を把握するというのはなかなか容易ではありませんが、
　それでも、帰納的に、情報探索・情報収集を通じて、私なりには、そのアウトラインを掴めてきたように思います。
　おおまかには、上記のエントリーの中でレポートしたような感じですが、
　実は、Drupal 7 においては、そこには挙がっていない非常に大きな変更がなされている、ということに気が付きました。
　そして、私的には、それこそが、Drupal 6 から Drupal 7 への最も大きな進化ではないか、と感じています。
　それは、drupal 7 における、「Entity」という概念・実装の導入です。
　簡単に言えば、「Entity」とは、「node」の上位概念であり、また、その実装です。
　Drupal 6 においては、Drupal が実体のあるコンテンツとして認識するのは「node」だけでした。
　サイト管理者や開発者は、CCK モジュールにより、
　「node」に自由にフィールドを追加し、様々なコンテンツタイプ（＝「node」タイプ）を作成することができたわけですが、
　どんなに複雑なフィールド構成にしようとも、それらはどこまで行っても「node」でした。
　しかし、Drupal 7 においては、「Entity」の要件を満たせば、
　Drupal が実体のあるコンテンツとして認識する全く新しいカスタムのコンテンツタイプを利用できるようになりました。
　「node」は、Drupal 7 においては、デフォルトの「Entity」タイプであり、最も重要な「Entity」タイプであると言えますが、
　唯一の「Entity」タイプではない、ということです。
　Drupal 7 のデフォルトの「Entity」としては、「node」以外に、「user」「term」「comment」などがあります。
　また、開発者は、様々なフィールドや様々な機能をもつカスタムの「Entity」タイプを、開発・実装することが可能です。
　さらには、今後は、特定の目的に即した「Entity」タイプが、Drupal Contrib として提供されるようになるかもしれません。
　このように、Drupal 7 への進化によって、Drupal は、これまで以上に、多様で高度なコンテンツを扱えるようになっています。
　そして、忘れてはならないのが、CCK モジュールから進化し、コアに取り込まれた Field モジュールの存在です。
　CCK モジュールが、「node」に対してフィールドの追加を可能にしたように、
　Field モジュールは、あらゆる「Entity」に対応し、それらに対して新たなフィールドの追加を可能にします。
　Drupal 7 においては様々な進化がなされており、それに伴う多くのメリットがありますが、私が情報収集した範囲においては、
　「Entity」と「Field」モジュールを活用できるということが、Drupal 7 の最も Drupal 7 らしい新機能であるように感じます。
　「Entity」と「Field」モジュールの連携が今後どのように発展していくのかについては、現状ではまだ未知数のようですが、
　Drupal 開発者として TransNetCreation においても、当サイトを Drupal 7 化するに当たり、
　まずは実験的に「Entity」と「Field」モジュールの開発・実装に取り組んでいますので、
　そこで感じたことなどについては、また、レポートできればと思います。

　TAG 1 :: DIARY :: AROUND THE CORNER :: Drupal

　※2011年03月08日追記
　　当サイトを Drupal 7 にアップグレードしました。
　※2011年03月24日追記
　　コラム Power of Drupal の vol.3 として、
　　「Drupal 7 における、オリジナル「Entity」導入のメリット・デメリット」というエントリーを公開しました。
　　この日記のエントリーの内容からもう一段踏み込んで、
　　TransNetCreation として オリジナルの「Entity」を開発・運用した経験 を踏まえて、
　　サイトオリジナルの「Entity」を導入することに関して、そのメリット・デメリットを考察しています。