Backbone.js с приложением без RESTful? (подходит ли Backbone.js для моего текущего проекта?)

Я пытаюсь выяснить, подходит ли Backbone.js для моего текущего проекта: приложения для визуализации.

У меня есть ряд вопросов:

1) Состояние/маршрутизация?

Поскольку это не обычное приложение RESTful, а скорее приложение визуализации с различными типами диаграмм и настройками для этих диаграмм, как сохранить состояние в URL-адресе? Допустим, моя модель areaChart имеет ряд значений по умолчанию, например:

AreaChartModel = Backbone.Model.extend({
    defaults: {
        selectedCountries: [],
        year: 1970,
        stacked: false
    },
    initialize: function(){
        [...]
    }
});

При обновлении модели я хотел бы сериализовать некоторые из этих атрибутов, чтобы добавить в закладки конкретное состояние: chartApp.html#!year=1970&stacked=false и т. д.

И наоборот, при запуске приложения с этим состоянием, как мне «депарамировать» состояние URL-адреса и установить модель? Могу ли я использовать внутреннюю маршрутизацию Backbone?

2) Контроллер и связь?

Кажется, что Backbone имеет довольно тесную связь между представлением и моделью? Это действительно то, как я должен привязать, например, мой areaChartView к модели?

AreaChartView = Backbone.View.extend({
    initialize: function(){
        areaChartModel.bind("change:year", this.render);
    }
});

Разве это не обычно роль контроллера?

3) Продолжение: модель или контроллер?

Учитывая этот сценарий: введите здесь описание изображения

Изменение в «Боковой панели» должно запускать последовательность функций:
1) «Должны быть загружены новые данные для текущего выбора»
2) «На основе этих данных должны быть обновлены шкалы в представлении «Визуализация». "
3) "Вид визуализации должен быть отрендерен"

Где я должен разместить эти функции и как я могу создать событие в модели, которое я запускаю, когда состояние стабильно? (т.е. когда все функции были вызваны и пришло время установить состояния просмотра?)


javascript model-view-controller javascript-framework backbone.js
person dani    schedule 23.05.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

1) Я бы максимально использовал нативную маршрутизацию Backbone.js, используя «:params» и «*splats» , подробнее. Вы можете уместить все свои запросы в маршрутизацию Backbone.js, но лично я бы пожертвовал некоторыми вещами в пользу интуитивно понятных кнопок пользовательского интерфейса.

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

Я бы, наверное, никогда не использовал ? и & в моих URL-адресах. Возможно, я вернусь к этому моменту позже, потому что это интересно.

2) Ваш пример хорош, и вам просто нужно помнить, что терминология Backbone.js MVC не коррелирует с традиционной MVC.

Представления магистрали по сути являются контроллером в традиционном MVC. Магистральные контроллеры — это просто способ маршрутизации внутри фреймворка. Механизм шаблонов, который вы используете с Backbone.js, — это традиционное представление MVC.

3) Все еще пишу

person Thomas Davis    schedule 23.05.2011
comment
Большое спасибо за ваш вклад. Это действительно прояснило: Backbone Views — это, по сути, контроллер в традиционном MVC. Механизм шаблонов, который вы используете с Backbone.js, — это традиционное представление MVC. Теперь я просто борюсь с № 3 - где разместить все функции, которые должны вызываться последовательно при обновлении модели. - person dani; 23.05.2011
comment
Большинство людей в настоящее время думают, что основной функциональностью контроллера является маршрутизатор из-за пакетов MVC на стороне сервера, которые пытались вписать MVC в другую парадигму. Поскольку контроллер всегда перерисовывает все представление, задача склеивания событий и представлений на сервере отпала. В традиционном MVC на стороне клиента контроллер отвечает за реагирование на события и обновление только тех представлений, которые в этом нуждаются. Однако маршрутизация хорошо вписывается в роль контроллера верхнего уровня для страницы (поэтому она может сохранять состояние как закладку). - person Juan Mendes; 19.01.2012

arrow_upward
0
arrow_downward

Что касается вопроса № 3, я бы создал Model и View для ползунка.

Затем я бы связал срабатывание события change в модели с некоторой функцией в представлении, которая обновляет представление графика (например, изменение масштабов). Что-то типа:

var Slider = Backbone.Model.extend({})

var SliderView = Backbone.View.extend({
    initialize: function() {
        this.model.bind('change', this.render);
    }

    render: function() {
        // load data, change scales, etc.
    }
});

var slider = new Slider();
var slider_view = new SliderView({ model: slider });

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

person asymmetric    schedule 08.05.2012

arrow_upward
0
arrow_downward

Сядьте на некоторое время и подумайте, является ли сохранение всего состояния хорошей идеей? Ключевыми мотивами для управления состоянием на основе URL-адресов является возможность поддержки кнопок навигации на основе браузера и возможность добавления страницы в закладки. В приложении визуализации ваши данные, вероятно, будут меняться каждую минуту. Это не то, что вы хотите сохранить в своем URL-адресе приложения. Вы действительно хотите, чтобы, когда пользователь добавляет ваше приложение в закладки и возвращается к нему через три дня, он видел визуализацию данных трехдневной давности? Для вашего сценария, если я правильно понял ваши требования, я бы рекомендовал сохранить состояние данных в самой вашей модели.

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

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

person lorefnon    schedule 24.09.2012