Рендеринг макетов с Backbone.js

StackOverflow https://stackoverflow.com/questions/4309954

  •  29-09-2019
  •  | 
  •  

Вопрос

Если бы вам нужно было создать одностраничное веб-приложение (SPWA) с использованием Backbone.js и jQuery, например, с двумя контроллерами, для каждого из которых требовались уникальные макеты страниц, как бы вы отрисовали макет?

  • ControllerA представляет собой макет из трех столбцов.
  • ControllerB - это макет из двух столбцов.
  • Маршрут по умолчанию активирует ControllerA.Welcome() - начальный рендеринг.
  • Оба контроллера имеют разные представления, отображаемые в их столбцах, которые используют все преимущества Backbone.js модели / представления.

В Чем Проблема

Когда пользователь запрашивает маршрут, сопоставленный с ControllerB, необходимо изменить весь макет страницы, чтобы больше не использовать макет ControllerA.Это скрыло бы макет ControllerA и показало макет ControllerB - или отобразило бы макет, если он еще не находится в DOM.

Моя Первая мысль

Могли бы вы использовать представление Backbone.js для визуализации макета, а затем отобразить каждый столбец с привязкой к модели?

Моя Вторая мысль

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

Вот фрагмент моей второй мысли:

var Controller = Backbone.Controller.extend
({
    routes :
    {
       "" : "welcome" // default action
    }
    /** Constructor **/
    ,initialize: function(options)
    {
        console.log('Workspace initialized');               
    }
    // LAYOUT
    ,renderLayout : function ()
    {
        console.log('Rendering Layout.');
        var $ = window.$;
        var layout = require('js/layout/app/big_menu');
        $(layout.parent).html(layout.html);
    }
    // ACTIONS
    /** Default Action **/
    ,welcome : function ()
    {
        this.renderLayout();
        console.log('Do the whole model/view thing...');
    }
});

Спасибо

Спасибо, что нашли время ответить.Я ценю это!

Это было полезно?

Решение

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

Это хорошо работает, когда у вас есть один макет, все становится весело, когда у вас есть несколько. Вы можете поместить все макеты на странице и скрыть различные конфигурации в зависимости от вашей логики. Вы можете видеть, что макет имеет первоначальный вид иерархии. Таким образом, вы отображаете макет, а затем получаете нагрузку представлений.

Нет настоящего способа сделать это. Есть плюсы и минусы для каждого. Одна вещь, которую я бы не сделал, это сделать макет в контроллере. Я положил все рендеринг и HTML в представлениях, чтобы я мог иметь дело с логикой на контроллере и модели (думаю, MVC здесь).

Другие советы

Я склонен согласиться с Жюльеном - приятно, что ваши макеты максимально не имеют состояния. Все всегда выкладывается на странице, по крайней мере, в форме скелета. Когда необходимо отобразить конкретный макет или конфигурация, вы лениво одавляете его содержимое и отображаете эту часть пользовательского интерфейса с помощью CSS. Взаимно эксклюзивные классы CSS полезны для этого, такие как: «Projects-open», «Documents-Open», «Notes-Open».

Я разрабатываю систему интрасети на основе модулей, используя backbone.js, и я в основном использую следующий алгоритм при загрузке документов.

  • Создайте AppController, одноэлементный контроллер для приложения.
  • AppController создает MainView, это представление, ответственное за рендеринг скелета страницы и обработку кликов для постоянных элементов на странице (кнопки входа / выхода и т.д.)
  • MainView создает несколько дочерних представлений для различных частей страницы, навигации, макетов, заголовка, панели инструментов, contentContainer и т.д.Это параметры приложения, и они не меняются, хотя их соответствующее содержимое меняется.Область содержимого, в частности, может содержать любой макет.
  • AppController проходит через зарегистрированные модули, инициируя mainModuleController для каждого из них.Все они имеют схемы маршрутизации пространств имен.
  • Магистраль.история.старт()

Все moduleControllers получают доступ к AppController при инициализации.При обнаружении хэш-местоположения они отправляют событие pageChange в AppController, содержащее объект pageManifest.Объект pageManifest содержит всю информацию, необходимую для настройки соответствующих представлений, такую как информация о хлебных крошках, информация о заголовке и, что наиболее важно, ссылка на созданный экземпляр contentView.AppController использует информацию в pageManifest для настройки различных постоянных представлений, удаляет прежний contentView в contentContainer и вставляет contentView, предоставленный модулем, в контейнер.

Таким образом, разные дизайнеры могут работать над разными модулями, и все, что им нужно знать, - это спецификацию объекта pageManifest и то, как должен выглядеть contentView.Они могут настраивать собственные сложные системы маршрутизации, использовать свои собственные модели и настраиваемые contentViews (хотя мы планируем наследовать библиотеку ListViews, objectViews и т.д.).

Сейчас мы находимся на стадии проектирования, поэтому я не могу гарантировать, что это именно тот дизайн, который мы в конце концов используем, или что мы не найдем в нем никаких недостатков, но концептуально мы считаем, что это правильно.Комментарии?

У меня есть тот же вопрос независимо от позвоночника или любых других JS Framework / библиотеки.

Представьте себе, что у вас есть знак представления формы, который требует единого макета столбца, и вы вводите представление в то, что один единственный Div.

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

Заголовок может содержать представление логотипа (если он имеет функциональные возможности) и представление мирового / пользователя. Левая зона будет содержать главный навигационный вид.

Тогда дальнейшая сложность.; Каждая ссылка внутри первичного вида навигации загружает новый подклад, готовый к дальнейшему представлению, чтобы вводить себя.

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

Я думал об использовании маршрутов (не в традиционном смысле) в умный способ что-то вроде:

function LayoutController() {
App.addRouteMatcher("/sign_in/*", this.renderSignInLayout); // single column
App.addRouteMatcher("regex to represent anything but sign_in", this.renderMainLayout); // header, footer, primary nav, main zone
App.addRouteMatcher("/section1/*", this.renderSubLayoutForSection1); // puts a 1 column layout in the main zone
App.addRouteMatcher("/section2/*", this.renderSubLayoutForSection2); // puts a 2 column layout in the main zone 
}

Это означает, что если маршрут был «/ раздел1 / что угодно / под / страница / в пределах / раздел / 1» два маршрута выше «Regeex, чтобы представлять что-либо, кроме« innight_in »и« / раздел1 / * », оба запускаются, что означает, что основной Макет будет отображаться, а затем в разделе «Section1 Sub» будет отображаться после того, как это имеет смысл.

Тогда все остальные обычные контроллеры используют маршруты в традиционном смысле.

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

Хотел бы услышать кого-то, что разработал и реализовал что-то элегантное.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top