Entity and Field APIの優れた点の1つは、フィールドを任意のエンティティ(ノード、ユーザーなど)に追加し、その後に任意のバンドル(ノードコンテンツタイプなど)を追加できることです。
しかし、Field APIまたはEntity APIを使用して、フィールド化可能なノードを作成する方法はありますか?つまり、フィールドインスタンスをコンテンツタイプ/バンドルの代わりに個々のノードにアタッチします。したがって、ノード1にはファイルフィールドとテキストフィールドがあり、ノード2には数値フィールドはあるがテキストフィールドがないなどです。
そうでない場合、同じ結果を達成する他の概念を使用して行われている作業はありますか?私が考えることができる最も近いものは Webform ですが、これはコンテンツを作成する方法を意図したものではなく、フィールドにField APIを利用していません。
作成時にエンティティをノードにアタッチすることでこれを行いました。
hook_node_insert()
の実装を作成します。この時点で、ノードは技術的にフィールド化可能です。フィールドをプログラムで作成するか、ユーザーが独自のフィールドを追加できるようにする何らかのUIを実装するかに関係なく、さまざまなことができます。
このアプローチには2つの落とし穴があります。
ノードとエンティティタイプは2つの別個の構造であるため、作成するバンドルがノードにリンクされていることを確認する必要があります。 Relation モジュールを使用していくつかの有望な作業が行われていますが、ノードIDを格納するエンティティバンドルのプロパティ(必要に応じて、ノードにバンドルIDを格納することもできます)。次にバンドル情報を hook_node_load()
にロードします。
バンドルをバージョン管理することは、私が入り込まないことを選択した重いウィザードです:APIはありませんが、理論的には、バンドルに加えたすべての変更のレコードを作成した場合、それはすべきです仕事、それはおそらく代わりに古い神々を目覚めさせるかもしれません。この方法でフィールド化可能にしたノードでリビジョンサポートをオフにすることを選択しました。
http://drupal.org/project/conditional_fields のようなものを使用できますが、これはすべてフロントエンドの観点から行われます。つまり、Drupalは意味しませんあなたの構造について本当に知っています。
http://drupal.org/project/properties は興味深く見え、ニーズによっては適切な場合があります。
最近同様の問題が発生し、1つではなく3つのコンテンツタイプに分割することにしました。
私は何かを逃しているかもしれないので、それは不可能ではないと言うのは難しいです。しかし、フィールドとフィールドのインスタンスに格納されているデータに基づいて、現在の設定はこれをサポートしていません。
私が考えることができる最良の解決策は、同じフィールドを使用して複数の画像を追加できるように、さまざまな種類の値を許可する特別なフィールドを作成することです。そのようなことをするのが良いアイデアかどうかはわかりませんが、それは確かに複雑で時間がかかり、おそらくすでに定義されているすべてのフィールドのコードを使用することはできませんでした。