Increasingly the metaphor of a "Window" is taking a back seat to the metaphor of a "Page", because with the success of the Web-Page model the window metaphor easily breakdowns in the face of web-like fluent user experiences. And though,
it is not technically hard to achieve composition in its simplest form, what has historically hurt is the lack of a proper/built-in composition model. Further the complexity and clumsiness of solutions like WPF Frames hasn't helped, that is without even considering
the locator, state-management, and navigation type issues the page metaphor brings. And in this scenario, nRoute really shines because it brings a simple and well-understood model for composition using Urls, along with inherent support for state management
and navigation features.
The composition model in nRoute is quite akin to IFrames in HTML, in that you point to a Url and it visualizes the content. However, rather than one all-purpose container like in Silverlight and WPF, we offer multiple so-called “Navigation Containers”
that by design offer different use-semantics like back-forward navigation, onwards only navigation, recurring state etc. Furthermore in terms of composition you can nest the containers, have them side-by-side, or just use a lone container for everything –
they are eternally flexible in being able to combine them and use them across namescopes. Think of these containers as being building-blocks for composition.
Navigation Handlers v/s Navigation Containers
Earlier when discussing navigation we specifically said to handle navigation one just needs a Navigation Handler, and Navigation Containers are Navigation Handlers just the opposite is not true. Or more specifically, Navigation Handlers are INavigationHandler
implementations, whereas Navigation Containers implement INavigationContainer which derives from INavigationHandler:
An INavigationHandler implementation is really bare-bones, and it just does two things – one it answers, as to if you can this navigation request, if so, then here handle it. And literally, you can tack it onto any existing control giving it instant capability
to partake in navigation (see the Extending nRoute section for more information). That being all well and good, the fact is normally one is used to directly using controls like the Frame control rather than extending existing controls for navigation – and
this is where we get the INavigationContainer and its derivatives. They provide the basics for navigation related controls with events and properties to match – and so we have four such built-in controls in nRoute. We also have a NavigationContentControl type,
that just implements the INavigationHandler interface. Lastly, unlike in Silverlight/WPF you are not constrained to just using any particular type to navigate (like the Page type), you can use just about any content type, furthermore your content doesn't need
to be aware of the container or vice-versa, as navigation happens without direct dependencies on the content type.