香港鬼片四个人打麻将:Integrating N2CMS into Who Can Help Me? Part 3

Integrating N2CMS into Who Can Help Me? Part 3

This is part 3 in my series of posts about integrating the .Net open source content management system N2CMS into the Sharp Architecture demo application Who Can Help Me?.

In the first and second post I

• Added the N2 assemblies
• Added the edit site to the web project
• Created the initial content definitions
• Created the database schema
• Added root nodes to the CMS database
• Updated the Web.config
• Set up the N2 Content Routes and intialised the CMS engine

Step 8 – Add a base CMS controller

To link our content items in the CMS database to the appropriate controllers, we need our CMS related controllers to inherit from the N2 controller class ContentController where T is the type of content definition that the controller is handling. This means that we have access to a strongly typed instance of the current content item that the controller is handling within our controller actions.

We already have a BaseController class in WCHM, as we wanted to set up some defaults for the master page name to use etc in the Spark views. Ideally, I’d like to be able to reuse this code, but as our CMS controllers need to be generic, I had to create a new base class, N2Controller which inherits the N2 ContentController and duplicate the method overrides for setting up the default master page etc.

Changeset reference 55248

I also added my specs for the behaviour of the base CMS controller:

What I’ve done here is add a base Index() action to the CMS controller that will just pass the current content item as the model into the view. In reality, I’ll probably not use this as in WCHM we’re pretty strict on using viewmodels to bind to our views, rather than domain entities (which is what the CMS definitions really are) however, this allows a quick and dirty way to pass the CMS content into the view as your’re building up your application. With anything but the most simple application, your view will be made up of more than just the content from the CMS, so you’ll need to build up a more specific model for the view anyway.

Note how N2 works – when it realises that it can handle an incoming request for a URL with a content item it creates that item for us and puts it into the RouteData before calling the associated controller. This means that we easily have access to the current item via the ContentController.CurrentItem property. We can easily simulate this for the purposes of our specs by adding a content item into the RouteData associated with our ControllerContext – (in the Establish context).

Changeset reference 55314

Step 9 – Update the HomeController

The goal of this exercise was to surface content from N2CMS onto our WCHM Home page and About page. We’ve now got a base CMS controller that we can use, so next I refactor the existing HomeController to inherit N2Controller.

The things to note are that we now inherit N2Controller which means we can easily access the current item (as a HomePage) from within our controller, and the Controls[] attribute, which tells N2 which content types this controller is going to handle. Any requests matching a content item of type HomePage will now come this way.

We also need to update our specs as because we now inherit N2Controller, which in turn inherits ContentController (in the N2 namespace), our controller is going to try to access the current content item out of RouteData. Even though we’re not accessing it yet, unless we put it into RouteData, our specs will fail. I updated the Establish context for the HomeControllerSpecs in the same fashion as the specs for our base N2Controller, by adding a content item into the RouteData associated with our ControllerContext.

Changeset reference 55315

At this point, our site should build, compile, pass tests and load up in the normal WCHM fashion, so lets take a pause and go off tangent ever so slightly…

Step 10 -  Authentication

This is a bit of a tricky one in WCHM as we’re already using Open ID for users to authenticate themselves in order to create profiles. N2 uses the Asp.Net membership providers to manage users and access to the CMS system (although it has it’s own custom provider that stores the users as content items in it’s own database). We don’t want to allow anyone to be able to get into the CMS, but we need to be able to distinguish between those that can and cannot with one unified mechanism.

I went round in circles a bit with this one, and with some help from Jon, I ended up back right where I started, which was to do nothing. The solution I came up with is a little hacky, but it works, and requires no changes to N2, or the WCHM authentication, so all is good for now.

In order to set up a CMS user, I first created a profile in the usual way in WCHM, using my preferred Open ID provider. I then opened the Profiles database table in the WCHM database and found the Open ID username that has been returned and stored against my profile. If, like me, you use a Google account, it will look something like this: (this is not my real Open ID!)

https://www.google.com/accounts/o8/id?id=asdasdasdasd6auasoas_asdadssad_das

I then used this username to create a new admin user in the N2 database in the normal way I would do in N2. Firstly, I need to add the relevant membership config for N2 into the web.config: