Почему все по-прежнему конструируют родительско-дочерние представления с использованием метода рендеринга?

Question

Я смею называть себя хакером.Я знаю, что может делать фреймворк и где его ограничения.У меня также есть некоторый опыт работы с несколькими шаблонными фреймворками.

Я видел много учебных пособий, в которых люди объясняют, как создавать сложные и вложенные представления, и большинство из них создают его частично с использованием шаблонов, а затем в методе рендеринга родительского представления, чтобы объединитьшаблонные дочерние представления

Для меня не имеет смысла, почему нужно иметь дело с визуализацией макета в декларативном коде.Исходя из Flex, меня учили никогда не делать этого.Я всегда оставлял описания макетов и привязки переменных к разметке, а затем обработку событий к декларативному коду (View instance), который использует эту разметку.

Однако ни одна из протестированных платформ шаблонов не позволяет создаватьсложной разметки, с вложенными представлениями.Нельзя реально вызвать шаблон из шаблона и, таким образом, создать экземпляр объекта View.Это представляется технически возможным, особенно с использованием атрибутов данных, где мы можем указать имена типов.

Затем все, что нужно сделать для метода рендеринга корневого класса View, - это превратить этот шаблон в разметку HTML, а затем выяснить, какими должны быть типы дочерних объектов, создать экземпляр дочернего представления для любого изих, и продолжайте в том случае, если эти дочерние объекты должны иметь дочерние объекты сами.Каждому представлению дается модельный контекст.В основном все стандартные этапы, которые мы выполняем постоянно, но автоматизированы на уровне Backbone.View.

Кто-нибудь еще думает об этом?Почему никто, кажется, не использует это?

Answer 1

Я согласен, что создание экземпляров дочерних представлений в методе render не имеет смысла. Хотя я не решусь полностью автоматизировать процесс, потому что я часто хочу передать дополнительные аргументы при инициализации дочернего представления, например:

var childCollection = someLogicToCreateTheChildCollection();

new ChildView({
  collection : childCollection
});

Итак, вместо этого я создаю все необходимые дочерние представления в initialize, а затем в render Я отображаю шаблон и назначаю дочерние представления для элементов в DOM.

Таким образом, моя функция рендеринга не является той, которая объявляет порядок DOM (как многие примеры показывают, добавляя) - шаблон устанавливает порядок DOM, а функция рендеринга просто setElement().render() - дочерние представления.

Answer 2

Следует отметить, что вообще не нужно использовать рендер, и он в основном зарезервирован для повторного рендеринга после внесения изменений в код. Вы можете связать представления напрямую на основе селекторов CSS (см. Документацию).

Кроме того, существует расширение привязки модели для Backbone, которое значительно упрощает привязку данных и сокращает необходимый «ручной» труд. Вы можете проверить это.

http://github.com/derickbailey/backbone.modelbinding

Наконец, я скажу это о рендеринге родительско-дочерних отношений. Не вызывать DOM в цикле . Это невероятно неэффективно, и, по крайней мере, одна из причин, по которой люди будут строить отношения между родителями и детьми только в методе визуализации родителей. Каждый рендеринг каждого дочернего элемента, скажем, с помощью jQuery, приведет к большой работе для браузера (если вы не замечаете этого в современном браузере, попробуйте в IE8).