Несколько основных страниц Durandal

Я работаю над SPA, в котором я хотел бы использовать несколько основных представлений. Вот мой вариант использования:

У меня есть пользователь, у которого есть страница профиля. На этой странице профиля я хотел бы иметь возможность отображать несколько разных представлений, т.е. детали, работы, контактная информация и т. д. Мне нужно иметь возможность глубокой ссылки на каждое из этих представлений. Каждое из этих представлений должно отображать основные пользовательские данные из основного вида макета.

Насколько я понимаю, для этого я должен использовать композицию, и у меня есть немного кода, который, кажется, работает, однако я хочу иметь возможность передавать данные из «вторичной оболочки» в фактическое подпредставление. Кажется, что данные пятна не передаются методу активации подмодели представления.

В моей «мастерской» модели представления я создал наблюдаемую с именем activeView, содержащую строку, соответствующую вспомогательной модели представления (модели представления/пользователь/детали). Затем у меня есть нокаутирующее заявление, которое выглядит следующим образом:

<!-- ko compose: {
    model: activeView(),        
    activate: true
} --><!-- /ko -->

Как я могу передать данные в подвид? Или есть лучший способ сделать это?

Заранее спасибо!


single-page-application knockout.js durandal sammy.js
person mcottingham    schedule 08.05.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

По моему мнению, ko.compose не такой динамичный и работает как макет Razor. С Durandal лучше создавать отдельные виды, насколько это возможно, а затем связать их с маршрутизатором. Я работаю с шаблоном Hot-Towel Джона Папы; Мое предложение касается передачи данных (больше, чем id) с маршрутизатором Durandal и нокаутом.

При инициализации вашего приложения (shell.js, main.js, ...) сопоставьте свои маршруты где-нибудь (shell.js или main.js) с настройками для последующей фильтрации. Для маршрутов, по которым будут передаваться данные, создайте их с предложением (:id)

router.mapRoute('view/:id', moduleId, 'Customer Details', false);

Где и когда нужны некоторые маршруты. Вы можете взглянуть на решение Джозефа Габриэля (https://stackoverflow.com/a/16036439/2198331), чтобы фильтровать маршруты для использования там, где и когда они вам нужны. После того, как вы отфильтруете маршруты, вы можете взломать routeInfo, чтобы передать свои параметры (строки или объекты, такие как selectedItem).

arearoutes = ko.utils.arrayFilter(router.visibleRoutes(), function (route) {
              // mgpe has been set at app init
                return route.settings.mgpe === 112; 
             });

расширьте свой routeInfo из результатов фильтра данными, которые вы хотите транспортировать

areaRoutes.forEach(function(ar){
     ar.myItem = mydata; // or vm.selectedItem(); DEPARTURE LUGGAGE
}, areaRoutes);

Ваш (myItem) теперь привязан к этим маршрутам так, как вам нравится Этот или эти маршруты будут нести ваши данные с собой и никогда не потеряются, если вы не обновите тот же объект маршрутизатора ( моя вещь)

function activate(adata){
       vm.arrivalData(adata.routeInfo.myItem);  // ARRIVAL LUGGAGE are here
}

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

router.activeItem.settings.areSameItem = function (currentItem, newItem, activationData) {
   mybag = activationData.routeInfo; // TRAVEL (current) LUGGAGE are present here
}

Н.Б. : прежде чем использовать этот обходной путь, вы должны рассмотреть проблему безопасности, и, поскольку я новичок в durandal, я не знаю, не приведет ли это к серьезным последствиям в жизненном цикле маршрута маршрутизатора. Также будьте внимательны с именами объектов, поскольку они остаются постоянными во время жизни маршрута маршрутизатора.

person M.Ouedraogo    schedule 09.05.2013

arrow_upward
0
arrow_downward

Как насчет того, чтобы создать пользовательский объект и потребовать его в каждой из ваших моделей представления? Проще всего было бы прикрепить его к приложению (например, app.user =). Изменения, внесенные в любой из наблюдаемых в указанном пользовательском объекте, будут обновляться для каждого из представлений и моделей представления в вашем SPA.

Таким образом, вы используете возможности sub/pub библиотеки нокаута.

person mhijazi    schedule 15.01.2014
comment
Приложение, которое я написал, требует такого поведения не только для пользовательских объектов. Durandal 2.0 представил дочерние маршрутизаторы, которые, по сути, позволяют пользователям создавать несколько вложенных оболочек с поддержкой глубоких ссылок. Естественно, для меня подходили детские маршрутизаторы. - person mcottingham; 16.01.2014
comment
Понял, эти две идеи (маршрутизация и датаконтекст приложения) работают вместе. Вы создаете SPA, который инициализируется на стороне клиента и редко отправляет полный ответ. Ценность, которую вы получаете, заключается в том, что вы можете подойти к разработке как к настольному приложению, а не как к традиционному веб-приложению, которое использует полную обратную связь. Это означает, что вы можете создать контекст данных, который сохраняет объекты в памяти. Таким образом, вам не нужно передавать объекты между представлениями, вы можете просто поддерживать глобальный контекст данных и передавать идентификатор в маршруте, используя параметры, а не целые объекты. - person mhijazi; 17.01.2014