Multiple Shells (views and view models) and routers for different type of users in Durandal

38 views
Skip to first unread message

Kendrick Junerto

unread,
Jan 29, 2015, 1:27:36 PM1/29/15
to duran...@googlegroups.com

So I'm trying to build an app that has two different kind of users, namely customers and sellers. The app is designed in such a way that both of them will have different kind of navigation bars and access to different kind of pages via routes. As such, I'm trying to see what is the best way to achieve this? I'm thinking of either of the following solutions: 1. using compose binding or areas in my shell.html and by having a container and based on a certain condition, the correct specific view (partial view)will be injected and the default binding context will be a common shell.js. However, the nav bar and each navigation panel displayed is determined by the routes that have

nav:true

and both seller and customer will have different routes that are marked nav:true. Is there a way to work around this limitation if we use this approach? 2. using compose binding but having two different views and viewmodels that we bind to our shell.html and shell.js. In other words, there will be two routers. However, I've read a number of posts about having two routers and apparently having multiple main routers in an app is not suggested. Is there another way I should approach this?I was having thinking of having multiple SPAs but I figure that would not be efficient since this is a mobile app. Any help or suggestion is greatly appreciated!

Kevin McGee

unread,
Jan 30, 2015, 1:14:26 AM1/30/15
to duran...@googlegroups.com
It is probably better to disclose how much of the full view inventory will be shared by the two classes of users.  If it is substantial, perhaps you can explore a means to dynamically set the router property "nav" based on credentials or identity, mostly likely in the Activate method of the Router.  This assume you can completely identify the user's role before instantiating the Router.

Just a thought.
Reply all
Reply to author
Forward
0 new messages