FubuMVC Diagnostics
This post is about the FubuMVC framework. For more info on getting started, click the previous link, or view the Getting started wiki page.
FubuMVC’s configuration model is a semantic model that is built up by an API. This allows great flexibility in how FubuMVC is configured as it could have several different ways of configuring it. Originally, we envisioned a conventional mode where routes are discovered and configured conventionally as well as another mode (thanks to input from Aaron Jensen) where routes would be explicitly defined up front and then matched to controllers and actions according to strict rules. There are several other modes/scenarios we thought of, but those two appear to be the most compelling.
As of this moment, in the source tree we have only completed one API/mode for configuring FubuMVC: the conventional one. For our application at Dovetail, we have a lot of actions that are very similar and conventional, so the conventional configuration of FubuMVC made sense for us to start with at first.
Having well-defined conventions is very nice in that it makes configuration a breeze and gets us away from reams and reams of XML or code for configuring our web framework. The down side is that because there is so much happening automatically to configure our routes, it gets hard to troubleshoot why something went wrong if we make a mistake.
We’ve tried to combat this problem by having lots of logging and diagnostics within the framework itself so you can see what actually got configured and even get some clues as to “Why” the conventional configuration mode did what it did.
Diagnostics Portal
NOTE: if you don’t already have a FubuMVC-based application up and running, you check out Tim Tyrrell’s super quick guide to getting started on FubuMVC.
Once you have your FubuMVC-based application up and running and you can successfully browse to your routes/actions, you should try hitting the FubuMVC diagnostics portal. First, make sure that you have enabled diagnostics in your Global.asax (if you’re using the FubuStructureMapApplication) by setting EnableDiagnostics = true, or (if you have your own FubuRegistry-derived class), passing true to IncludeDiagnostics(bool). Next, navigate your browser to http://
Chains
“Chains” means “Behavior Chains”. FubuMVC executes routes by using a sort of chain-of-command pattern (not exactly chain-of-command, but it’s similar). Many “behavior nodes” or “behaviors” are chained together and each get an opportunity to service part or all of the request. Some examples of behaviors are “Invoke the action”, “Render a WebForm view”, “Log the request”, “Render output model as JSON”, etc. Behaviors get associated with chains conventionally through your configuration. To view all the chains that are available, click on the “Chains” link. At which point you’ll see a screen something like this (from the FubuMVC HelloWorld sample application):
In this screen, you can see that there are four routes/chains/actions (actually, there are more, I cut out some others for the sake of keeping the image as small as possible).
You should also note (as an aside), that there is a special “(default)” route and two methods that are HTTP method-constrained. Joshua Flanagan detailed the HTTP method constraining capabilities of FubuMVC in his recent post “Define your actions your way.”
When you click on a chain (I clicked on “(default)”) you’ll see a screen with more detail including the behaviors (“Nodes”) and a short log (I’ll explain this in a second):
Chain – Nodes
This table represents all the behavior “nodes” in the behavior chain for this route. Here we can see five behaviors. Three of them are diagnostic behaviors (behaviors that enable the FubuDebug tracing feature described in an upcoming post). So let’s ignore them for now. If you had diagnostics disabled, there would only be two behaviors in this chain: The “Call” behavior and the “Output” behavior. The “Call” behavior is the one that will actually call your controller action method. The “Output” behavior is, as you can probably guess, responsible for actually binding the output of the action method to the view and rendering it. This is a very simplistic example. Real-world apps would likely have several more behaviors attached for example one to log the request, one to start a database transaction, etc.
Chain – Log
The log output gives you a window into how all the conventions in your FubuRegistry contributed towards the configuration of this route/chain. If the right behavior didn’t get wired up or the wrong one did, this log may reveal the answer “Why”. This is helpful for troubleshooting in large applications where conventions are complex and may even collide in some circumstances. Using the log can help you make your conventions more explicit so as to avoid collisions or misses.
Routes
This screen is very similar to the “Chains” view, except it shows the Route, the Action that will be executed, what the Output will be, and then has a link to the chain view for this route. The “Routes” view is helpful if you want a quick view of which routes map to which actions or output views.
Actions
This screen is similar to the others, but is organized by Action, alphabetically. This screen is useful if you’re investigating why a particular action is behaving the way it’s behaving.
Inputs
This screen lists all the input model types and their associated actions. In FubuMVC, action routes are usually (but not only) identified by their input model types (since FubuMVC prefers the one-model-in, one-model-out style of action methods). You can request the route/URL for a given input model type in FubuMVC. If you’re not getting back the expected URL for the specified input type, use this “Inputs” view to help track down why it’s not working right.
Summary
In this post I showed you how to enable and view the FubuMVC diagnostics portal and what the various screens in the portal mean. I hope that this portal assists you in learning about FubuMVC and to troubleshoot any problems that may come up when setting up your application.