冒頭の画像は英語版の標準プロファイルでインストールして状態から取り出したコンテンツ情報保管に関わるyml構成ファイルをUMLと対応させたものだ。Entityで、そもそもDrupalでどうやってコンテンツを管理しているのかを眺めていた。この記事はその続きの理解をメモしたもの。RDB等に格納するためのマッピングは、field.storage.*.*.ymlに記述されていて、その中にtranslatable:booleanが定義されている。Translation)していることが分かる。field.storage.node.bodyというフィールドストレージは、field.field.node.article.body(コンテンツタイプ:記事)とfield.field.page.node.body(コンテンツタイプ:基本ページ)で同じものを使いまわしている。field.field.node.*.*特定のコンテンツタイプのフィールド定義でもtranslatable:booleanがある。ちなみに、コンテンツタイプを定義するnode.type.*でnew_revision:booleanがあり、field.*の方にはnew_revisionに相当するものはない。リビジョン管理の単位はコンテンツの単位で行いフィールドのレベルで行うわけではないのが分かる。逆に、node.type.*の方にはtranslatableに相当する構成はない。tagsのようになっている。異なるボキャブラリのタームを同じストレージに納めて良くて、そのコントロールはコンテンツタイプ側のフィールド定義に責任をもたせている。実装が見えてくると、リビジョン管理と多言語管理がうまく独立できているのが分かるが、一方で、公開ワークフローが難しくなるのがよく分かる。moderationを適用すると、公開しているコンテンツのリビジョンが最新とは言えないし、翻訳が追いつかなければ、場合によっては当該コンテンツの翻訳版を非公開状態に変える必要があることもあるだろう。言語と時間経過という2つの軸を扱わなければいけないので難しくなる。整理した軸がまた交錯することになるのでバグが入りやすくなる。それでもアドホックに対応するよりは遥かにマシだろう。entity構成ファイルには、core.entity_view_display.node.article.teaseのような表示に関わるものもある。contentという記述があり、フィールドを描画するための指示情報が記述されている。こちらもimageモジュールで処理してレンダリングにつなげているのだろう。気になるのは、ヘッドレスの時代、あるいはデータとしてのコンテンツ参照が進むとレンダリング機能は分離されなければならなくなることだ。CMSのコンテキストで考えると、レンダリングはThemeに依存してしまう。フレームワークにBootstrapを使うかW3cssを使うかで実質的に可能な表現力は変わる。ThemeのようにThemeとフィールド機能をモジュールの橋渡しをするようなレンダリングに資する機能をもつモジュールが必要になってしまう。フレームワークが10あって、データ型(field定義モジュール)が100あれば1000のレンダリング支援モジュールが必要になってしまう。コンテンツのオーサリングを考えれば、imageモジュールが、core.entity_form_display.node.article.defaultによるレンダリング支援に対応できないと困るが、結構悩ましい問題だと思う。experienceの観点では、さらに時間がかかるだろう。それでも、アドホックアプローチでシェアを稼ぐCMSより、地味でも確実にインフラのレベルを高めているDrupalに将来を感じている。タグDrupalfeedbackこちらに記入いただいた内容は執筆者のみに送られます。内容によっては、執筆者からメールにて連絡させていただきます。