orktane

The la MVC routing framework I showed last week, well I have decided to call it "nRoute" (pronounced enroute). With "n" being ambiguous for either any or .net, which by some coincidence carries the suggestion to route anything or routing for .net ;)

So now that it has a name badge, let see what's under the hood:

1. Routing Services

   The routing service is almost a direct port of the asp.net MVC routing engine. However, in this case it is relatively more generic and has a more forthright request-reply semantics. Also, we only do play with relative URLs here, that said you normally wouldn't have to interface with this directly. This falls under the Routing namespace.

2. Navigation Services

   This builds directly atop the routing services, but offers its own set of APIs to handle navigation functionality. The interesting thing (and what I wacked my brain around a lot for) is that you can navigate against a handler (as in saying you want this thing to handle the navigation for this URL) or directly consume the navigation reply. That flexibility befits a lot of edge-cases scenarios, yet is very simple. This falls under the Navigation namespace.

3. Navigation Containers

   I like to think navigation containers represent models for consuming navigation in different ways. They ultimately manifest as UI controls, but what they represent is different ways to navigate like a browsing with back-forward capabilities or vanilla navigating without any trace. In WPF you have something similar, but it is inherently very opaque and inflexible in this case it is relatively simple to cook up a custom container. However, you can do without them entirely. They fall under the Navigation.Containers namespace.

4. Application-Level Integration

   One of the most wanted features in RIA apps is deep-linking, and that requires hooking with (at the application-level) a navigation container to handle URL requests. For that purpose, I want to provide a specialized Application class with accompanying navigation events, and maybe a Visual Studio template to shrink-wrap it. Also, I have modelled an asp.net like Site Map API, again for application level consumption. This is work in progress. 

5. RoutingCommand Services

   The idea is to use URLs as signifiers of commands, kinda like the commanding pattern in WPF. I am still working on the details but I think it might useful in application-wide commanding scenarios, especially since it is loose-coupling through URLs, and like elsewhere we can also pass-in name-value parameters. Further, I am looking to support event type multi-casting, but it is still entirely on the drawing board.

6. Re-routing Services

   The idea here to have some kind of built-in re-routing capabilities that allows you to change the URL without breaking existing links and the apps. This is just a future-proofing initiative, as it might be useful in cases where you have many independent / modular components and links need to be changed. Also work in progress.

That's a 10,000 ft overview; I hope you enjoyed the flight and the pilot informs me the code will be landing soon on Codeplex (too cheesy?)

Anyway, I am well aware that possibly by next week this could all be an elaborate road-kill courtesy Silverlight 3, but I am holding the fort till then. In any case, SL 3 will definitely have an application-level navigation framework, but my understanding is that it will be more akin to asp.net type mapping with real folder/file-path mapped one-on-one with relative URLs. Thus, the contrast it might have with nRoute will be in the same order that MVC routing has to asp.net file mapping; lets see how it figures.

One other thing is even though nRoute offers a somewhat different paradigm for application flow, it doesn't pre-empt the use for frameworks like Prism or Caliburn. In fact I would rather this be used in hand with the mentioned frameworks.