2013-03-28 4 views
1

Так что у меня есть небольшая проблема.Магистральная маршрутизация, несколько маршрутизаторов после backbone.history начинается

Я в ситуации, когда мне нужно иметь несколько Backbone.Routers, которые обрабатывают свои собственные маршруты соответственно и т. Д., И я динамически загружаю их на основе того, что основной маршрутизатор (Router 1 в следующем примере) знает о маршруте В данный момент.

Основная проблема, с которой я сталкиваюсь, - это что-то вроде этого.

  • router1 грузы
  • Backbone.history.start()
  • router1 грузы Роутер2
  • Роутер2 dosen't сделать что-нибудь, потому что история уже началась

Есть ли возможный путь я может получить router2 для просмотра текущего фрагмента истории без повторного вызова маршрутов в маршрутизаторе1?

IE не вызывает вручную Backbone.history.loadUrl (Backbone.history.getFragment());

Edit:

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

+0

Если вам нужен динамический способ обработки маршрутов, и основной маршрутизатор определит, как генерируются эти динамические маршруты, почему бы вам не создать коллекцию выражений регулярных выражений и функции обратного вызова, которые вы используете для своих вторых маршрутов, и передать оба функции url, regex и callback для метода внутри вашего основного маршрутизатора. Как правило, это управление маршрутами. Только одним способом, я уверен, что есть лучший способ сделать это. – Kalpers

+0

Хм это может сработать, есть ли у вас какие-либо подробности метода? – adrian

ответ

0

Не могли бы вы предоставить jsfiddle, который воспроизводит ваш случай? Потому что вы могли бы нормально сделать это (. У меня лично есть приложение инстанцирование маршрутизатора, начиная историю, инстанцирование несколько других из них, и это работает прекрасно)

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

Редактировать:Редактировать:
Хорошо, я думаю, вы хотите, чтобы оба маршрута выполнялись, потому что вы ожидаете, что кто-то получит прямо в tab1/stuff.
Ужасный способ: вы можете остановить Backbone.history (Backbone.history.stop()) и запустить его сразу после этого, маршруты маршрутизатора будут связаны ...
Другая возможность: почему бы вам не поместить все ваши маршруты в ваш основной маршрутизатор? Ну, я думаю, если у вас действительно слишком много, это понятно.
Последняя возможность (что я могу придумать): использовать тот факт, что сначала маршрутизируются маршруты последнего маршрутизатора, и это то, что вам нужно. Измените маршруты основного маршрутизатора, добавьте общий, который поймает то, что вам нужно (например, tab1). Не делайте ничего, перейдите назад в/tab1. Приготовьте 2 Переходит, как это:

this.navigate('/tab1', {trigger: true}); 
this.once('someEvent', function() { 
    this.navigate('/tab1/stuff', {trigger: true}); 
}); 

Если у Вас есть достаточно общие URL-адреса, вы можете заменить tab1 & материал с аргументами вы бы соответствовать с вашим общим маршрутом.

Edit 2:
Ok вот редактировать предполагая все, что я писал в своем последнем комментарии, и что доступ Ваше мнение остов с хэштегом (или URL), как вид/действия. Я постараюсь быть более основательным, каким я могу быть (потому что у меня все еще не все детали вашей проблемы).

This jsfiddle показывает принцип. Теперь все еще есть тот факт, что он будет конфликтовать с историей клиента (возможно, есть способ избежать этого в Backbone, я думаю, вам нужно будет изучить это, если это проблема для вас).

Теперь, факт, что может быть несколько других проблем. Наименьший из них может быть шаблоном во вторичных маршрутизаторах (вы должны поставить вид/ перед любым маршрутом). Для этого есть решения, но это будет слишком глубоко. Более крупным является следующее:
Я уже говорил об этом, но только один маршрут будет согласован. Таким образом, ваш основной маршрутизатор CANT будет использоваться, чтобы иметь дело с тем, что клиент изменит вид (скажем, от view1/action1 до view2/action2, router2 уже загружен ранее). Действие2 будет выполнено, но если вы перезагрузите свои представления в своем основном маршрутизаторе, это не будет сделано.
Как последний комментарий, вы можете изменить метод инициализации ядра маршрутизатора после создания основного маршрутизатора, чтобы добавить поведение шаблона (перезагрузить свой вид?): here's an example, который может вам подойдет.

+0

https://gist.github.com/amchang/5264260, вы получаете основную идею, в идеале в этой ситуации мне бы хотелось, чтобы маршруты router2 выполнялись, хотя технически это не создавалось при запуске истории. – adrian

+0

Итак, с вашим последним предложением вы в основном говорите, что это особый случай, подождите, пока «async'event» будет вручную перемещаться? – adrian

+0

Это было немного моего кода, я боюсь, что событие async было добавлено мной (будучи дома, я не могу смотреть в него сейчас, я проверю завтра). Но идея состоит в том, чтобы прослушать то, что скажет вам, что вы можете перемещаться еще раз, потому что все загружено (здесь ваш второй маршрутизатор). – Loamhoof

2

Предлагаю вам посмотреть на MarionetteJS, который является отличным каркасом для построения композитных приложений с помощью базовой линии. В частности, посмотрите исходный код MarionetteJS example app. То, что он делает, - это разделить приложение на несколько подприложений. Каждое суб-приложение имеет свой собственный маршрутизатор, но все они определяют отдельные маршрутизаторы в родительском приложении. Когда родительское приложение инициализируется, все маршрутизаторы создаются, и только тогда вызывается Backbone.history.start(). Я понимаю, что этот ответ требует, чтобы вы погрузились в Marionette, у которого крутая кривая обучения, но я думаю, что это того стоит. Мы построили всю архитектуру SOOMLA designer web-app поверх нее. Marionette зарекомендовала себя как отличное решение, когда вы хотите перерасти свой повторяющийся шаблонный шаблон. Kudos to Derick Bailey для потрясающей рамки с открытым исходным кодом.

Смежные вопросы