D8の普及とともにMediaモジュール(core)が徐々に受け入れられるようになって来ていると思い、最近imageフィールドではなくMediaへのリファレンスを利用しようと考えるようになった。
まず最初にimageフィールドとMedia(entity)はどう違うのかを振り返ってみると、imageフィールドはファイル参照で、widgetでページ表示の表現を調整する。具体的には、ConfigurationのImage stylesを登録設定して表示画像の大きさや切り抜きなどの操作を定義して、Content typeの表示管理で表示方法を決める。Mediaの場合はentity参照で、特定のMedia typeのインスタンスとして扱われるので、Content typeの表示管理でのwidget設定はMedia typeのView modeを指定することになる。特定の局面だけで考えると、やれることは変わらない。Media typeの定義の中では、imageフィールドが使われていて、Image styleの適用も同じである。一段、構成定義が深くなるので、一件定義するだけなら、Mediaを使わないほうが定義の手間は軽い。
Mediaは、imageだけではな動画やYoutube等のリモート動画、音声、TwitterやInstagram等の外部コンテンツを統一的に扱えるようになっている。よく考えると画像ファイルも外部コンテンツでExifが埋め込まれていたりする。撮影時刻や位置情報など目に見える画像以外の情報もファイルの中に含まれているのだが、その情報を取り出すことができなければ意味を持たない。
Media typeの定義画面を見ていると、フィールドマッピングという定義がある。remote videoの場合にはデフォルトでは、Name（Content typeのTitleに相当）だけがマッピングされるようになっているが、当該Media typeのFieldを定義すれば、例えばYoutube動画をMidiaとして定義した時に動画の幅や高さの情報を取ってきて、Mediaの属性として管理することができる。
ここでふと気づく。コンテンツとは何か、フィールドとは何か、という問いである。
Webサイトを構築する時には、とりあえず「絵が出せれば良いじゃん」、画像サイズの問題が発生すると「レスポンシブ対応を考えなくちゃ」という形で検討が進んでいく。ヘッドレスでバックエンドはDrupalを使いつつスマホアプリを作ろうとか考えるとまた対応が必要になる。改めて、表示の問題とコンテンツの分離が十分でないことに気づかされるのである。
あるコンテンツのBodyフィールド（Text (formatted, long, with summary)）でイメージとMediaを挿入したケースのソースを見てみよう。
<p><img alt="Minsk" class="img-fluid" data-entity-type="file" data-entity-uuid="e7c92585-feef-4cc2-9d4f-ef9a1ad97343" src="/sites/default/files/inline-images/IMG_20191117_131514.jpg" /></p>
<p> </p>
<drupal-media data-align="left" data-entity-type="media" data-entity-uuid="53d131ed-af84-4f4e-901d-b685f8e8d31f" data-view-mode=""></drupal-media>
最初のimgタグはHTMLそのもので、Mediaを埋め込んだdrupal-mediaタグはそれ自身はそのまま描画できるような情報ではない。data-alignは描画位置のヒント、data-view-modeは描画フォーマットのヒントで、data-entity-uuidがentityのIDを示している。実際にはこのentityはYoutube動画なのだが、このソースだけでは、mediaであること以外はわからず、中身を見に行くと初めてどのようなコンテンツかがわかる仕組みになっている。抽象化レベルがimgタグより高い。ヘッドレスの実装では、明らかにやれることが違ってくるだろう。
こういう事に気がつくたびに、おおっDrupalすげー、と思うのだ。逆に、Drupalが難しいと言われる原因でもあると思う。
表題に戻って、EntityとView modeを再考すると、もともとContent typeには表示管理(Manage display)があり、DefaultとTeaserがほぼ最初からView modeとして設定されている。ユースケースから考えるとDefaultは全項目表示で、Teaserは一覧表示したときの表現で、表題とサマリーだけとか、そんな感じの使い方が想定されている。View modeは、内部で管理しているコンテンツには影響を与えない。あくまで描画時に参照される定義情報となる。フィールドレベルでも描画時の情報を制御する必要があり、例えば日付のフィールドで、年月日表示にするか月日表示にするかが問題となる。これはWidgetを使って設定する形になっているが、これも結構難しい。localeがja_JPのときとen_USの時では描画は違って当然である。考えていくと切りがない。
MediaのView modeを考えると、レスポンシブで表示したいとか、画像の上にNameを重ね書きしたいなどのニーズが考えられる。音声の場合は、再生ボタンを描画させたいかとか、コンテンツとUIは別物である。Media typeで定義されているFieldは検索（絞り込み）対象になるし、Mediaの導入で抽象化が一段進んだことが分かってくる。プラットホームの特性によって、できることできないことがあるけれど、それぞれの構成要素の背景となるモデルを理解しようとすることはとても大事なことだと思う。
ふと、Addressフィールドのことを考えると、宛先はコンテンツで宛名表示はView modeとして考えられて良いように思った。見方によっては、翻訳もMedia typeに刺激を受けて考えると本文にはオリジナリティや著作権などのメタ情報が付随していて、翻訳文には翻訳文固有のメタ情報がある。目に見えるものあるいは得たい結果から考えると関心の外にある情報をどう管理していくのかを考え始めると、プラットホームが対応できていないと手が届かないことが分かってくる。Drupalがこれからも生き残っていくとすると、Mediaだけでなく、基盤となるようなcoreのフィールドが拡張され、標準化が進んでいくのだと思う。CLDRやschema.orgとの連携の重要性も意識されることになるだろう。逆に言えば、自分でコントロールできない範囲が広がるとも言える。オープンソース文化の成熟が必要なのだろう。
アジャイルなアプローチも良いのだが、モデルを丁寧に作って積み重ねていくのも悪くないと思うのだ。社会の底上げにつながる。