Блог

Я пишу свое первое Marionette приложение и хотел бы использовать структуру Marionette пользовательского интерфейса.

Я понимаю, что, грубо говоря,

• A Region равен 1: 1 с существующим единственным DOM-узлом (например, a div или a span ) и может содержать View s, включая специальные, предоставляемые Marionette
• A Layout — это a View , а также контейнер Region s и указывает a template , с помощью которого будут упорядочены эти области; в качестве a View он может быть отображен в Region

Итак, я думаю, это означает, что вы должны следовать такой иерархии:

 - Root (region) [could be more than one]
-- Layout A
--- Inner Region A1
--- Inner Region A2
-- Layout B
--- Inner Region B1
--- Inner Region B2
-- View C
--- maybe some subviews?
  

Если мои предположения неверны, пожалуйста, исправьте.

В любом случае, в моем приложении есть область навигации и содержимого в пользовательском интерфейсе. Теперь, когда скрипт загружен, мы можем загружать его на страницу, на которой уже есть div#region-navigation возможность настроить внешний вид, или мы можем загружать его на страницу без узла на месте. Если узел навигации на месте, нам не нужно его отображать, но нам нужно иметь возможность поддерживать ссылку на него и выполнять с ним какие-либо действия (например, «Войти в систему»=> «Выйти из системы»). С другой стороны, если его нет на месте, нам нужно его визуализировать и поддерживать.

Мой вопрос: каков «марионеточный» способ справиться с этим? Я подумал об одном способе, но мне бы очень хотелось избежать каких-либо излишне болезненных путей.

Мое решение состоит в том, чтобы создать абсолют RootRegion , который является единственным селектором (по умолчанию body ), который определенно не существует на момент создания.

У меня было бы два AppLayout s: an InjectedAppLayout , где в макете есть только Content область, и a ManagedAppLayout , где макет заменяет содержимое body .

Затем на основе параметров script тега data- и / или того, что находится на странице (с использованием jQuery) Я могу выбрать, что Layout использовать.

В любом случае у меня есть a HeaderRegion и a ContentRegion . В случае InjectedAppLayout HeaderRegion , если объект находится снаружи, в то время ManagedAppLayout как объект содержит оба. Тогда мне, возможно, потребуется создать отдельное ExternalHeaderRegion и InternalHeaderRegion / или использовать условное, потому что мне нужно будет обрабатывать вещи по-разному в зависимости от того, управляется ли оно мной или нет.

Это кажется очень неоптимальным, но я не нашел ни одного примера того, как люди справляются с этим.

Наконец, в случае an InjectedAppLayout , я боюсь, что div содержимое ContentLayout может быть очень маленьким, даже если ширина экрана большая, потому что я его не контролирую. Все мои стили, запросы using Bootstrap и media используют max-width значения для определения того, какие стили устанавливать. Мой вопрос: будут @media (max-width: XXXpx) ли запросы по-прежнему применяться к содержимому div в случае внедренного макета приложения?

Я использовал следующую структуру

 -Marionette Application (root - have regions hash of existing node elements)
-- LayoutView (breaks application region in sub regions if needed)

---CollectionView || CompositeView (render collections)
----ItemView
||
---LayoutView (create more sub-regions) 
---- (other sub views)
||
---ItemView (render model)
  

Маршрутизатор и контроллеры для статусов приложений поддерживают

Позволяет разделить ответы между этими материалами

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

1) Может получить некоторые дополнительные параметры при запуске

 var options = {
  something: "some value",
  another: "#some-selector"
};

MyApp.start(options);
  

2) наличие регионов должно работать с существующими узлами (навигаторы, содержимое, нижний колонтитул, боковые панели и так далее)

 MyApp.addRegions({
  someRegion: "#some-div",
  anotherRegion: "#another-div"
});
  

Таким образом, вы можете предоставить некоторые параметры JS для отображения правильных представлений вы можете подключить свое приложение к элементам узла

Маршрутизатор и Контроллер

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

 var MyRouter = new Marionette.AppRouter({
  controller: myController,
  appRoutes: {
    "foo": "doFoo",
    "bar/:id": "doBar"
  }
});
  

LayoutView
Отвечает за рендеринг и закрытие вложенных представлений. Отдельный родительский узел в некотором дочернем узле

 Backbone.Marionette.LayoutView.extend({
  template: "#layout-view-template",

  regions: {
    menu: "#menu",
    content: "#content"
  }
});
  

Используя эту структуру, вы можете передать приложению некоторые параметры, чтобы сообщить приложению, вошел ли пользователь в систему или нет. В соответствии с этим вы можете добавлять регионы с помощью addRegions и отображать некоторые макеты (например, ‘UserNav’ или ‘GuestNav’). Макет будет отображать свои дочерние представления, такие как пользовательские ссылки, UserAvatar и так далее. Затем пользователь щелкает ссылки, маршрутизатор и контроллер обрабатывают это и сообщают приложению, что отображать в каком-либо регионе.