Backbone.js + GUI: нужно ли создавать графический интерфейс с представлениями и моделями или я загружаю его с помощью html с самого начала?

Question

До сих пор я создал только небольшие тестовые приложения, и я не знаю и не знаю, как лучше использовать backbone.js для графического интерфейса полноценного приложения.

Я вижу даже самый маленький пример наДокументация backbone.js:

var Sidebar = Backbone.Model.extend({
  promptColor: function() {
    var cssColor = prompt("Please enter a CSS color:");
    this.set({color: cssColor});
  }
});

window.sidebar = new Sidebar;

sidebar.bind('change:color', function(model, color) {
  $('#sidebar').css({background: color});
});

sidebar.set({color: 'white'});

sidebar.promptColor();

означает ли это, что мне нужно обернуть каждый элемент моего графического интерфейса в модель и посмотреть на нее?или это будет считаться плохой практикой?

У меня такое ощущение, что это будет слишком сложно, и я очень хорошо смог бы просто загрузить графический интерфейс уже в HTML-файл, и сделать модели / представления только дляэлементы графического интерфейса, для которых требуется динамическое содержимое.

, чтобы четко сформулировать вопрос: является ли хорошей идеей создание моделей / представлений графического интерфейса?если да, вы создаете 1 глобальный вид?или действительно построить каждый элемент в представлении?(верхний колонтитул / боковая панель / панель навигации / область содержимого / нижний колонтитул / что угодно еще ...)

Answer 1

Уровень представления Backbone в основном основан на соглашениях, а не обеспечивает богатую иерархию предопределенных виджетов и менеджеров компоновки, таких как традиционная структура графического интерфейса. Backbone вообще ничего не делает для создания вашего графического интерфейса, кроме предоставления рекомендованной структуры для модуляции уровня представления в слабосвязанные, независимые секции, которые могут автоматически обновляться в ответ на действия пользователя или обновления модели. На каком уровне вы должны модулировать, полностью зависит от вас. Вы можете создать свою собственную иерархию вложенных представлений, например. вид боковой панели, содержащий верхнюю панель инструментов и нижнюю панель инструментов, а также вид списка, занимающий основное тело, и этот вид списка будет дополнительно содержать виды элементов списка, которые могут быть отображены. Нужно ли переходить на этот уровень детализации, полностью зависит от ваших потребностей. Например, если список навигационных ссылок на боковой панели статичен и никогда не меняется, то этот уровень вложенности представлений является просто излишним. Но, тем не менее, если ваше представление списка прикреплено к коллекции или вам нужно вложенное дерево связанных элементов, которые постепенно извлекаются с сервера, тогда вышеприведенный подход - путь. Правило большого пальца состоит в том, что ваш уровень представления делится на классы представления только до тех пор, пока он не станет более удобным.

Answer 2

К сожалению, это во многом вопрос "зависит".это зависит от того, что нужно сделать вашему приложению, насколько вам нужен контроль над HTML через магистральные объекты и т. д.

Не думаю, что вы найдете «правильный ответ» на этот вопрос, поскольку это очень субъективно.

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

Я также настоятельно рекомендую купить скринкасты Peepcode и Tekpub для backbonejs.они стоят каждого пенни.если вы не выполняете какую-либо работу с asp.net mvc 3 на бэк-энде, вы, вероятно, можете пропустить серию tekpub mvc 3 (где находится эпизод с опорой).

есть также много отличных блоговпосты и ссылки реализации там, если вы ищете их.