This is part 2 of a 2 part series. If you missed part 1, you can read it here.
Creating a view and corresponding view model
DurandalJS uses a "Composition Engine" which uses KnockoutJS to bind a view to its corresponding view model. They’ve included a pretty handy router module that takes the pain out of wiring up the application’s navigation, so let’s just add a view for each widget in order to keep the sample clean. Open up the “app folder” and inside you’ll see folders for “views” and “viewmodels”. I want you to open the “views” folder and make two copies of the “flicker.html” file. Name one of the copies “combobox.html” and the other one “texteditor.html”. Now open up the “viewmodels” folder and make two copies of the “flicker.js” file. Name one of the copies “combobox.js” and the other one “texteditor.js”. We’re going to have to make changes to all four of these new files, but before we get into that, there’s something important that we need to do.
Configuring the router module
We have two new views and two new corresponding view models to go along with them, but there’s no way to actually get to them at run time unless we configure the router first. To do that, we have to open up the “shell.js” file found in the “viewmodels” folder. I want you to make the following changes to the array in the router activate function: 
This does three really cool things:
- It adds our new views to the application’s navigation module
- It routes the appropriate view into the applicationHost
- It maps the appropriate module (view model) to the correct view.
Configuring the view models
We’re going to need to wire up all of the needed scripts (modules) and binding logic for our widgets in our view model files. First up, we need to tell Durandal which modules to load in order to get our view working properly. This is another one of those moments in the process where you really need to consider exactly what resources the view model is going to need. Let's take a closer look: 
What we’ve got up there is the view model for the ComboBox. Let’s step through this. The define function is a RequireJS thing. We’re only going to load in the scripts that are needed to make these widgets work properly. Of course, what I’m really talking about here are which modules to load. Let me explain: Take a look at that define function, and first up, you’ll see some parameters that have been defined by Durandal’s composition engine. After that, you’ll see some Wijmo entries. Do they look familiar to you? If not, go back to the “Configuring RequireJS to load Wijmo” section. How about now? Here’s the kicker: We don’t need to grab every single namespace listed in the RequireJS config inside of “main.js”. In fact, all we need to grab is the module in charge of driving the logic of whichever widget we’re working with. There’s a potential gotcha here if you aren’t paying attention though: We also need the interop scripts if we’re going to be using KnockoutJS for data binding, or Bootstrap for styling the widgets. Those are necessary modules too. In essence, we’re grabbing the modules that we need to run the view and view model since they’re both going to be bound by KnockoutJS at the application level and then pushed into the applicationHost by that handy router module. The only other task left to do in the view models is to set up any observable bindings at the widget level. To make this easy, I’d like you to head over to the Wijmo demo page and open up the knockout samples. I’m going to be using the source from the ComboBox and Text Editor samples. Since we’re already working in the view model, we don’t have to create a separate view model like we’ve done in the samples on the Wijmo site. So, instead of setting the observables up like this: 
We'll set them up like this: 
I’m going to be linking to a sample at the end of this blog post, so be sure to refer to it to see how I set up both of the view models.
Configuring the views
We’re going to be replacing the default flickr markup in these views with the markup from the appropriate knockout samples. This is really convenient since all of the bindings are present in the source of the samples. Once this is done, you should now be able to navigate to each of these new Wijmo views directly from the navigation.
Debugging
If you didn’t include all of the dependencies in the RequireJS config, this is where you’re going to run into some issues. I’d suggest opening up the console to see what you might be missing. 
Thankfully, you'll see exactly what’s missing. Once you’ve taken care of the dependencies, you’re finished!
Conclusion
Well, that’s it! You now have a DurandalJS application capable of using Wijmo’s entire widget set which will certainly enable you to hit the ground running in your SPA development. I think it’s pretty cool how well our widgets meshed with this framework. As promised, here is the link to my sample. If you have any questions, you can leave a comment here on the blog, or post in the Wijmo forum. Thanks for reading!
MESCIUS inc.