2014-10-30 3 views
0

В настоящее время я работаю над крупномасштабным Backbone-приложением (с использованием marionetteJS) и с некоторыми проблемами архитектуры с лучшими практиками/шаблонами, участвующими в переключении просмотров или изменении «страницы».Изменение «страницы» в MarionetteJS

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

Thats easy. Трудная часть для меня - это понимание того, что лучше всего подходит для запуска этих изменений.

Вот некоторые из решений, я пришел с:

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

  2. Когда пользователь нажимает на ui, чтобы изменить страницу, представление запускает команду и передает в представление, которое она хотела бы изменить на ui, например App.execute('page:change', view). Объект приложения прослушивает этот триггер и отображает представление, которое передается в представление основного макета приложения.

Проблема с первым методом является то, что контроллер должен знать о каждой странице в ее рамках (возможно это еще не плохо, я не знаю). Например: просмотр списка пользователей, просмотр-просмотр-просмотр пользователей, просмотр-просмотр-просмотр и т. Д. Это также делает код более сложным, поскольку отслеживать события происходит повсюду.

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

Есть ли какая-либо передовая практика для такого рода вещей?

EDIT:

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

+0

Дерик рекомендует [агрегатор события на уровне приложения] (http://lostechies.com/derickbailey/2012/ 04/03/revisiting-the-backbone-event-aggregator-lessons-learn /), который сказал, что этот вопрос не подходит для SO, и его лучше спросить у [программистов] (http: //programmers.stackexchange. ком). Голосование закрывается. – steveax

+0

, когда я ссылаюсь на 'page: change: x' или' App.execute'. Я действительно говорю об агрегаторе событий уровня приложения, реализованном по умолчанию в marionettejs. – Tom

ответ

1

Столкнувшись очень близко выпуск несколько раз, мое решение следующих

1) Главное - единственный сценарий в HTML-страницы, загружает приложение + маршрутизатор + контроллер 1) Применение - определение корневых областей, начинается история, 2) AppRouter - следить за действиями для сопоставления URL-адресов и вызовов. 3) AppController - сохраняет действия хеш-событий, подписываются событиями (например, App: switchpage) с собственными действиями, управляют моделями и представлениями.

В коде (я использую requireJS для загрузки по требованию):

главное.JS

define(
    [ 
     'application', 
     'appRouter', 
     'appController' 
    ], 
    function(Application, Router, Controller) { 
     var App = new Application; 

     App.addInitializer(function() { 
      this.controller = App.Controller; 
      this.router = App.Router({ 
       controller: this.controller 
      }) 
     }) 
    } 
); 

Применение

define(
    [ 
     'marionette', 
     'backbone' 
    ], 
    function(Marionette, Backbone) { 
     return Marionette.Application.extend({ 
      regions: { 
       'main': '#body' 
      }, 

      onStart: function() { 
       Backbone.history.start() 
      } 
     }) 
    } 
); 

appRouter

define(
    [ 
     'application' 
    ], 
    function(Application) { 

     Application.module('AppRouter', function(Module, App, Backbone, Marionette) { 
      App.Router = Marionette.AppRouter.extend({ 
       //for example : page/home page/goods page/user 
       appRouter: { 
        'page/*': 'switchPage' 
       } 
      }) 
     }) 
    } 
); 

AppController

define(
    [ 
     'marionette' 
    ], 
    function(Marionette) { 

     Application.module('AppRouter', function(Module, App, Backbone, Marionette) { 
      App.Controller = Marionette.Controller.extend({ 
       switchPage: function(path) { 
       //path (user || home || some) 
        require(['views/'+path], function(pageView) { 
         App.main.show(new pageView) 
        }) 
       } 
      }) 
     }) 
    } 
); 

страница/дом

define(
    [ 
     'marionette', 
     'underscore' 
    ], 
    function(Marionette, _) { 
     return Marionette.ItemView.extend({ 
      template: _.template("home page") 
     }) 
    } 
); 

Его просто макет, я удалил некоторые части коды, чтобы сохранить только идею применения. Чтобы сделать его более масштабируемым, вы можете определять страницы как модули со своими собственными средствами управления и депо.

Nightly рекомендуем оформить Brian Mann скринкаст в http://www.backbonerails.com/, особенно Engineering Rich, Single Page Apps И фотографии Дэвид Шульц GitHub с project example

+0

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

+0

Ссылки IMO - лучший способ, потому что это означает, что вы можете переходить к одному и тому же состоянию страницы при совместном использовании ссылки или открытии ссылки на новой вкладке. – Quince