MSDN Magazine - March 2008 - (Page 51)

First, it creates a NewVersionPostData object. This is another helper object that has properties and methods that store the contents of the post and some validation. To load up the postData object, I’m using a helper function from the MVC Toolkit. UpdateFrom is actually an extension method provided by the toolkit, and it uses reflection to match up the names of form fields to names of properties on my object. The net result is that all the field values are loaded into my postData object. Use of UpdateFrom does have the disadvantage, however, of getting form data directly from HttpRequest, making unit testing more difficult. The first thing the NewVersion checks is SubmitAction. This will be OK if the user clicked the OK button and actually wants to post the edited page. If any other value is here, the action ends up redirecting back to ShowPage, which just redisplays the original page. If the user did click OK, then I check the postData.Errors property. This runs some simple validations on the post contents. If there aren’t any errors, I do the processing to write the new version of the page back into the wiki. However, if there are errors, things get interesting. If there are errors, I set the various fields of the TempData dictionary so that it contains the contents of the PostData. Then I redirect back to the Edit page. Now, since the TempData is set, the page will redisplay with the form initialized with the values the user posted the last time. This process of dealing with posts, validation, and TempData is a little aggravating right now and requires a bit more manual work than is really necessary. Future releases should include helper methods that automate at least some of the checking of TempData. One last note on TempData: the contents of TempData are stored in the user’s server-side session. If you turn session off, TempData won’t work. Figure 13 Controller Factory public class WikiPageControllerFactory : IControllerFactory { public IController CreateController(RequestContext context, Type controllerType) { return new WikiPageController( GetConfiguredRepository(context.HttpContext.Request)); } private ISpaceRepository GetConfiguredRepository(IHttpRequest request) { return new FileBasedSpaceRepository(request.MapPath(“~/WikiPages”)); } } Controller Creation it with the MVC system. You can register controller factories for all controllers or just for specific types. Figure 13 shows a controller factory for WikiPageController, passing the repository now as a constructor parameter. In this case, the implementation is pretty trivial, but this can enable the creation controllers that use much more powerful tools (in particular dependency injection containers). In You can implement the any event, now I have all IViewFactory interface, and the details of getting the dependencies for the controlthen you’ve got complete ler separated into an object control over how the output that’s easier to manage and is generated. maintain. The last step in making this work is to register the factory with the framework. I do this via the ControllerBuilder class by adding the following line to Global.asax.cs in the Application_Start method (either before or after the routes): ControllerBuilder.Current.SetControllerFactory( typeof(WikiPageController), typeof(WiliPageControllerFactory)); The basics of the wiki are now working, but there are a few rough spots in the implementation I’d like to clean up before going further. For example, the Repository property is used to decouple the logic of the wiki with the physical storage. You can provide repositories that store content on the file system (just as I’ve done here), a database, or wherever else you want. Unfortunately, I’ve got two problems to resolve. First, my controller class is tightly coupled to the concrete FileBasedSpaceRepository class. I need to have a default, so that if the property’s not set, I have something reasonable to use. Even worse, the path to the files on disk is hardcoded here as well. At the very least this stuff should come from configuration. Second, the Repository is really a required dependency; my object won’t run without it. Good design indicates that the repository should really be a constructor parameter, not a property. But I can’t add it to the constructor because the MVC Framework requires a no-argument constructor on controllers. Luckily, there’s an extensibility hook that can get me out of this bind: the controller factory. A controller factory does much like the name says: it creates Controller instances. You just need to create a class that implements the IControllerFactory interface and register This will register a factory for the WikiPageController. If I had other controllers in this project, they wouldn’t use this factory, since it’s registered only for the WikiPageController type. You can also call SetDefaultControllerFactory if you want to set a factory to be used for every controller. Other Extensibility Points The controller factory is just the start of the framework extensibility. I don’t have space in this article to get into details about all of them, so I’ll just hit the highlights. First, if you want to output something other than HTML or if you want to use a templating engine other than Web Forms, you can set the controller’s ViewFactory to something else. You can implement the IViewFactory interface, and then you’ve got complete control over how the output is generated. This is useful for generating RSS, XML, or even graphics. The routing system is quite flexible, as you’ve already seen. But there’s nothing in the routing system that is specific to MVC. Every route has a RouteHandler property; so far, I’ve always set this to MvcRouteHandler. But it is possible to implement the IRouteHandler interface and hook the routing system up to other Web ASP.NET MVC march2008 51

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.