Backbone.js с не RESTful-приложением?(Подходит ли Backbone.js для моего текущего проекта?) - PullRequest
Новая
       35

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

5 голосов
/ 23 мая 2011

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

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

1) State / Routing?

Поскольку это не ваше типичное приложение 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) Продолжение: Модель противКонтроллер?

При таком сценарии: enter image description here

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

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

Ответы [ 3 ]

3 голосов
/ 23 мая 2011

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

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

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

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

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

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

0 голосов
/ 25 сентября 2012

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

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

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

0 голосов
/ 08 мая 2012

Что касается вопроса №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 });

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

...