This project is read-only.

Navigation at its core is a very simple service – basically, the idea is to translate a Url based request into a response, that some specified handler can then visualize. And, that’s exactly what happens internal to nRoute, even though you are generally abstracted away from handling these specific classes:


So for example, under the hood when you click on a button to navigate, essentially you create a navigation request (as in Step 1) identifying a handler (normally a UI container) which gets passed to the Navigation Service. Thereon the Navigation Service asynchronously resolves the response (normally a UI Control) using the Routing Engine (as in Step 2), which it then passes to the Navigation Handler that knows how to use it (as in Step 3). One important detail that is not shown above is the translation from a Url to a Response (like a UI Control), well, that is a part that you need to fulfil by earmarking a resource as being representative of a Url – we broadly call this call mapping.

Now the above is the internal workflow to nRoute, as far using nRoute’s navigation infrastructure is concerned, it involves three things:

  1. Mapping Urls to Resources
  2. Implicitly or explicitly specifying a Navigation Handler to handle the response
  3. Requesting for the Url

And per this listing, we are going to next look into navigation mapping that binds Urls to navigable content, use of navigation containers that can visualize navigation responses, and how to perform navigation itself by requesting for Urls. This workflow is relatively quite simple, though it is flexible and powerful enough to handle almost all kinds of real-world uses.

Last edited Aug 29, 2010 at 5:38 PM by Orktane, version 2


No comments yet.