長らくコードを書かずに独自データ型を定義したいと思っていた。
ノードで定義して、Entity referenceで組み込んだり、タクソノミー・タームで定義して組み込んだりして対応しているのだがどちらもオーバースペックで余計な機能がついてきてしまう。Paragraphsはレンダリングに寄っていて、型定義に流用するのは抵抗があるし、多言語対応に難がある。
TheWeeklyDropの1月20日号で、Storage 1.1.1がリリース紹介欄に出ていたことで、Storage Entitiesモジュールの存在を知った。
A new entity type for managing data that should be stored in the database, but only displayed within or associated with other content.
...
Lightweight by design, but fieldable just like content types.
とあったのが関心を惹いたのだ。
実際に入れてみると、メニューやフロントページへの掲載属性やBodyフィールドもついてこない軽量版のnodeのようなもので、ちゃんと翻訳機能に対応している。加えて、権限でバンドル単位で公開制御が可能となっている。
ユースケースの一つとしては、聖書がある。
マルコによる福音書、1章、1節を表すデータ型を定義して、それを参照する、文語訳、口語訳、新共同訳などの聖書の文章を記述するデータ型を定義して、コンテンツを登録したい。これができれば、参照関係を記述するのも容易になる。版権の問題はあるが、日本語版のBilbe Hubサイトを立ち上げて、Wikipedia的に衆智を集めることができるようになる可能性がある。
もちろん、様々なマスターデータに対応できるようになる。特に有効だと思うのは、(Storrage type)フィールド単位でアクセス権が設定できるから、権限の分離が進む。法人コードなどへの応用も可能だろう。オープンデータの普及にも貢献できると思う。
WebCMSはWebサイトを素早く作れるころが求められるので構造が壊れやすい。その中ではDrupalはコードに頼ることなく構造化原則を維持できる稀有なプラットホームだ。それでも、ノードもタクソノミー・タームも太ってしまっていて、Drupal8でEntityとして整理し直す決断をしたことで、構造を維持できる道を広げたと同時に少なくない開発者を失った。Storage Entitiesモジュールはノーコードで構造化原則の維持を可能にする良い試みだと思う。
※画像は、モジュールのページから引用させていただいたもの