Routing

Coordinator
May 23, 2008 at 6:00 PM
Before I begin, let me say that I know this is not an optimal approach but for build 1. We are unfortunately faced with a situation of dramatically declined interest and as a result, we must put speed of coding over efficiency and elegance. With that said, here's how the routing will operate:

The Page table is going to warehouse both content pages and blog pages. The content pages are going to be "default" and will not require a controller prefix but rather will be a catchall. Any additional controllers will require a prefix in the routes. For example:

"Manage/{controller}/{action}/{id}"
"Shop/{action}/{id}"  <-- Shop controller
"Blog/{*catchall}"     <-- Blog controller, RouteCheck action, param = catchall
"{*catchall}"             <-- Page controller, RouteCheck action, param = catchall

Both the blog and the page controllers will have an "RouteCheck" action that accepts a string as a parameter. The RouteCheck action will invoke the GetPage sproc that returns relevant information about the page such as it's action, view, name, and so forth. The RouteCheck action will then use RedirectToAction to complete the routing process. These steps are only necessary for pages that have dynamic routing.

Advantages:
  • Easy to use tree-structured page
  • No forced unique naming of pages.
  • Eliminates the need to have the controller present for standard pages.
  • Easy to manage actions
Disadvantages:
  • Confusing - it is a messy solution and will be resolved in later editions
  • Inefficient - it wastes resources bouncing all over the place