Режимы просмотра речевого сигнала
По-моему, я не объявляю this.el, потому что я создаю его динамически, но таким образом события не срабатывают.
Это код:
Просмотр 1:
App.Views_1 = Backbone.View.extend({
el: '#content',
initialize: function() {
_.bindAll(this, 'render', 'renderSingle');
},
render: function() {
this.model.each(this.renderSingle);
},
renderSingle: function(model) {
this.tmpView = new App.Views_2({model: model});
$(this.el).append( this.tmpView.render().el );
}
});
Вид 2:
App.Views_2 = Backbone.View.extend({
initialize: function() {
_.bindAll(this, 'render');
},
render: function() {
this.el = $('#template').tmpl(this.model.attributes); // jQuery template
return this;
},
events: {
'click .button' : 'test'
},
test: function() {
alert('Fire');
}
});
});
Когда я нажимаю кнопку ".button", ничего не происходит.
Спасибо;
Ответы
Ответ 1
В конце вашего метода render() вы можете указать опорную точку для повторных событий, используя delegateEvents(). Если вы не передадите какие-либо аргументы, он будет использовать хэш событий.
render: function() {
this.el = $('#template').tmpl(this.model.attributes); // jQuery template
this.delegateEvents();
return this;
}
Ответ 2
Как и в Backbone.js v0.9.0 (30 января 2012 г.), существует метод setElement для переключения элемента views и управления делегированием события.
render: function() {
this.setElement($('#template').tmpl(this.model.attributes));
return this;
}
Backbone.View setElement: http://backbonejs.org/#View-setElement
setElementview.setElement(элемент)
Если вы хотите применить представление Backbone к другому элементу DOM, используйте setElement, который также создаст кешированную ссылку $el и перемещение представление делегированных событий от старого элемента к новому.
Динамически создавая свои взгляды таким образом, есть плюсы и минусы:
Плюсы:
- Вся ваша HTML-разметка вашего приложения будет сгенерирована в шаблонах, потому что элементы корня Views заменены на разметку, возвращенную из рендеринга. На самом деле это красиво... больше не искать HTML внутри JS.
- Хорошее разделение проблем. Шаблоны генерируют 100% разметки HTML. Представления только отображают состояния этой разметки и отвечают на различные события.
- Предоставление рендеринга для создания всего представления (включая его корневой элемент) соответствует тому, как ReactJS отображает компоненты, поэтому это может быть полезным шагом в процессе миграции из Backbone.Views в компоненты ReactJS.
Минусы: - они в основном незначительны
- Это не будет безболезненный переход на существующую базу кода. Необходимо обновить представления, и для всех шаблонов необходимо будет включить элементы списка View root, включенные в разметку.
- Шаблоны, используемые несколькими видами, могут быть немного волосатыми - Будет ли корневой элемент идентичным во всех случаях использования?
- Прежде чем вызывать вызов, корневой элемент представления бесполезен. Любые изменения в нем будут выброшены.
- Это будет включать родительские представления, устанавливающие классы/данные в элементах дочернего представления до рендеринга. Это также плохая практика, но это происходит - эти модификации будут потеряны после того, как рендер переопределит элемент.
- Если вы не переопределяете конструктор Backbone.View, каждое представление будет излишне делегировать его событиям и устанавливать атрибуты корневому элементу, который заменяется во время рендеринга.
- Если один из ваших шаблонов разрешает список элементов, а не один родительский элемент, содержащий детей, у вас будет плохое время,
setElement
захватит первый элемент из этого списка и выбросит остальное.
- Вот пример этой проблемы: http://jsfiddle.net/CoryDanielson/Lj3r85ew/
- Эта проблема может быть устранена с помощью задачи сборки, которая анализирует шаблоны и гарантирует, что они разрешат один элемент, или переопределяя
setElement
и гарантируя, что входящий element.length === 1
.