仲間のフロントエンド開発者が私にこの質問を投げかけました、そして私は私のスタンスを明確にする方法が正確にわかりませんでした、しかし彼は私に考えさせました:
したがって、Backbone(またはBackbone.Marionette)の規則では、テンプレートに関連付けられたビューをレンダリングしてから、結果のビューの構築/合成されたHTMLを既存のコンテナーにダンプまたは追加します。
this.$el.append(this.subview.render().$el);
ただし、もちろん、これには、この新しくレンダリングされたビューをにダンプするために、すでにレンダリングされているページ上のDOM要素が必要です。これにより、次のような現象が発生します。
<ul id="scheduler-loadroutegroups" class="full-height"></ul>
また
collectionView.$("#scheduler-loadroutegroups").append(itemView.el);
つまり、最終的にコンテンツを期待する空のコンテナです。
明らかに、このレンダリングと追加のパターンはBackboneのコアコンセプトであり、コンテンツを配置するためのコンテナーを持つことは絶対に不可欠であるように思われます。
私の同僚の質問は、空のコンテナーを必要としない、よりサーバー側のMVCテンプレートパターンを利用できるかどうかでした。
<ul id="scheduler-loadroutegroups" class="full-height">
{{#developers}}
<ul>
{{#pets}}
<li>{{name}}</li>
{{/pets}}
</ul>
{{/developers}}
</ul>
この例では、開発者がモデルのコレクションを表し、ペットがモデルのコレクションを表すとします。それぞれに、イベントが添付された独自のビュー/サブビューが必要になります。
より古典的なサーバー側のMVCテンプレートシステムの問題は、ビューとそれに関連するテンプレートで、Backboneが依存するコンテキスト制限とイベントバインディングをきめ細かく制御できないことだと思います。
私が見たすべてのバックボーンの例/ドキュメントは、この「空のコンテナ/追加」パターンを使用しています。他の方法で何かをすることは可能ですか?なぜまたはなぜそうではないのですか?