Несколько маршрутизаторов против одного маршрутизатора в BackboneJs

Все примеры на Backbone, которые я видел, используют один маршрутизатор для всего приложения, но не имеет смысла иметь маршрутизатор для каждой отдельной части вашего приложения (заголовок, нижний колонтитул, этап, боковая панель)? Кто-нибудь создал приложения с несколькими маршрутизаторами и каковы ваши впечатления?

Подумайте о сложном приложении с вложенными представлениями: не было бы лучше, если у представления есть свой собственный маршрутизатор, который обрабатывает отображение подзонов, чем наличие одного большого маршрутизатора, который должен сообщить основному виду, чтобы изменить его subviews

Предыстория этого вопроса: я вижу много параллелей маршрутизатора в магистрали и ActivityMapper в GWT. ActivityMapper несет ответственность только за то, чтобы получить правообладателя для данного маршрута и данного контейнера в DOM.

Ответы

Ответ 1

Я написал приложение (все еще записывающее) с несколькими маршрутизаторами. однако это не так, как вы думаете, это больше основано на модуле, а не маршрутизатор для каждого представления или что-то в этом роде.

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

// user module...
var userRouter = Backbone.Router.extend({
    routes: {
        "users": "loadUsers",
        "users/add": "addUser",
        "user/:id": "loadUser",
        "user/:id/edit": "editUser"
    }

// ... rest dropped to save the trees (you never know if someone prints this out)
});


// book module
var bookRouter = Backbone.Router.extend({
    routes: {
        "books": "loadBooks",
        "books/add": "addBook",
        "book/:name": "loadBook",
        "book/:name/edit": "editBook"
    }

// ... rest dropped to save the trees (you never know if someone prints this out)
});

поэтому, это не так, как мои два маршрутизатора конкурируют за один и тот же маршрут, каждый из них обрабатывает свой собственный набор маршрутов.

изменить теперь, когда у меня появилось больше информации через Эльфа Штернберга, я знаю, что по-умолчанию невозможно сопоставить несколько маршрутизаторов на одном и том же маршруте. без обходного пути, например, переопределение истории магистрали или использование пространств имен в маршрутах и регулярных выражениях для соответствия этим маршрутам. подробнее здесь: несколько маршрутов соответствия спасибо Эльф Штернберг за ссылку.

Ответ 2

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

Ознакомьтесь с записью в блоге для получения дополнительных пояснений: http://www.geekdave.com/?p=13

Это означает, что вам не нужно избыточно определять один и тот же префикс снова и снова, и вы также можете использовать подпрограммы lazy-load при доступе к модулю. Обратная связь очень приветствуется!

Ответ 3

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