Charles Nurse

DotNetNuke 6.2, Beta 1 - Registration Enhancements

Tue, 10 Apr 2012 08:00:00 GMT

As part of building a robust Social platform, we have added a number of enhancements to Registration.

Registration, Login and Profile Settings

DotNetNuke is a very powerful and flexible platform. The challenge that this brings is that it is often difficult to know where to make configuration changes. User/Registration settings is one such area. In this Beta we have tried to address this by moving the Registration settings to the Admin/Site Settings page. Admins are familiar with going to this page to make configuration changes.

DotNetNuke Module Development 101: 2 - What is a Module?

Wed, 04 Apr 2012 08:00:00 GMT

This blog has been cross-posted from my personal blog.

In the first post in this series I pointed out that DotNetNuke places few requirements on module developers, and this is often daunting to new developers – “where do I start?” being a common refrain.

So where do you start?

Before we actually start to build our first module lets look at what constitutes a module. In the default DotNetNuke skin/template that is used when installing DotNetNuke there are a number of examples of Text/HTML modules.

As an example Figure 1 shows 3 such modules on the Home Page.

DotNetNuke Module Development 101: 1 - I did it My Way

Fri, 30 Mar 2012 08:00:00 GMT

This blog has been cross-posted from my personal blog.

DotNetNuke has a rich eco-system of Modules, both Open Source and Commercial. In many ways this is our biggest strength as a CMS platform. No matter what you want to do with your site – there is often a module that already does it.

In my opinion this is due to the flexibility provided by the core DotNetNuke Framework. Many other platforms are very prescriptive – as an extension developer you have to follow a fixed shopping list of rules – there is invariably only one way to create an extension, which may not work for what you want to do.

Tags: Module Development

Category: Development

DotNetNuke 6.2 CTP 1: Profile Changes

Fri, 02 Mar 2012 08:00:00 GMT

DotNetNuke 6.2.0 CTP 1 introduces a number of Profile updates - many of which update the Visibility options.

Admin-Only Properties - while this has always been available through the Visible property, this has been made clearer in the Help text for the property.

A Profile Property whose Visible property is false cannot be viewed in the Profile page by the user (but is visible to Administrators when they edit the user's profile, and is available to Module Developers through the API).

DotNetNuke Patterns and Practices - 2: Testable Controllers

Thu, 01 Mar 2012 16:35:58 GMT

So here it is – the first real post in our series on DotNetNuke Patterns and Practices. How do we make our “Controllers” testable.

Historically, DotNetNuke has used a “Repository” style for manipulating entities in the business layer (rather than an Active Record style) – a lightweight Entity class – usually suffixed with Info, and a Repository class which has traditionally used Controller as a suffix.

This naming strategy was present initially in the iBuySpy Portal Starter-Kit upon which DotNetNuke is based. Thus, for instance, if the business layer needs to model Task objects, there will be a TaskInfo entity and a TaskController repository class.

Back in 2002/3 when DotNetNuke was first created, developers were not so concerned about whether they could write Unit Tests, so the pattern of use was that whenever a “controller” was needed it was constructed on the fly. If that controller in turn needed to call a 2nd controller then it was also constructed on the fly.

The problem, from a modern perspective is that it is difficult to write Unit Tests using this pattern, as there are unknown dependencies that cannot be mocked or faked.

Dependency Injection

One of the ways to solve this is to use Dependency Inversion. This principle is one (the D) of the SOLID Principles of Object Oriented Design espoused by “Uncle” Bob Martin and others (we will review these principles in future articles in this series). The “Dependency Inversion Principle” says that any dependencies should be based on abstractions not concretions.

Dependency Injection supports this by injecting any dependency in the form of an Interface (or abstract base class), usually through the Constructor.

So if ControllerA has a dependency on IControllerB then ControllerA’s constructor should look like the following:

private IControllerB _controllerB;

public ControllerA(IControllerB controllerB)
{
    _controllerB = controllerB;
}

The class that is constructing a ControllerA would need to also construct a concrete implementation (ControllerB) of IControllerB and pass it as a parameter.

IControllerB controllerB = new ControllerB();

ControllerA controllerA = new ControllerA(controllerB);

In a Unit Test, the dependent interface can then be mocked, using a mocking framework like Moq or RhinoMocks or faked by creating a FakeControllerB which has a known behavior.

Dependency Injection Containers

We can make this simpler by using a Dependency Injection Container. DotNetNuke has a simple Container and we can use this container to register all of our controllers. This can reduce some of the plumbing that we have to do.

For example, we can create an instance of ControllerB and add it to the Container.

ComponentFactory.RegisterComponentInstance(new ControllerB);

Now we can modify the ControllerA class by adding a second constructor with no parameters.

public ControllerA()
    : this(ComponentFactory.GetComponent())
{
}

With these changes in place we can go back to our original pattern of constructing an instance of ControllerA.

var controllerA = new ControllerA();

When writing Unit Tests the dependency on IControllerB can be resolved by mocking or faking IControllerB and adding the mock (or fake) to the Container as part of the test setup.

There are some examples in the core of this pattern.

Service Location

An alternative approach to Dependency Injection is to use Service Location. In Service Location we call some service to locate an instance of the Interface that we need.

The Container in DotNetNuke is actually an example of Service Location.

var b = ComponentFactory.GetComponent();

In 6.2 we have introduced an abstract base ServiceLocator class that manages the service location.

    public abstract class ServiceLocator where TSelf : ServiceLocator, new()
    {
        private static TContract _instance;
        private static bool _isInitialized;

        protected static Func Factory { get; set; }

        public static TContract Instance
        {
            get
            {
                if (!_isInitialized)
                {
                    if (Factory == null)
                    {
                        var controllerInstance = new TSelf();
                        Factory = controllerInstance.GetFactory();
                    }

                    _instance = Factory();
                    _isInitialized = true;
                }

                return _instance;
            }
        }

        public static void SetTestableInstance(TContract instance)
        {
            _instance = instance;
            _isInitialized = true;
        }

        protected abstract Func GetFactory();
    }

How this works is best shown with an example. In the CTP we have refactored the RoleController to use this new service location pattern.

We have extracted an interface – IRoleController – from the original RoleController class:

    public interface IRoleController
    {
        int AddRole(RoleInfo role);
        void DeleteRole(RoleInfo role);
        RoleInfo GetRole(int portalId, Func predicate);
        IList GetRoles(int portalId);
        IList GetRoles(int portalId, Func predicate);
        IDictionary GetRoleSettings(int roleId);
        void UpdateRole(RoleInfo role);
        void UpdateRoleSettings(RoleInfo role, bool clearCache);
    }

Next we implemented a concrete implementation of the Interface – RoleControllerImpl (which is too long to show in its entirety here).

Finally we created a class which inherits from the new ServiceLocator class – TestableRoleController.

    public class TestableRoleController : ServiceLocator
    {
        protected override Func GetFactory()
        {
            return () => new RoleControllerImpl();
        }
    }

This now works in a similar way to the way we use our providers. To call a method on the RoleController, we call the Instance method, which returns the current Instance of the interface.

TestableRoleController.Instance.AddRole(role);

The Instance property of the abstract ServiceLocator base class will return an instance of the interface (IRoleController). By default the GetFactory method is setting the internal instance to be the concrete implementation (RoleControllerImpl) but the base class also has a method SetTestableInstance. We can now use this method to change the internal instance to a Mock or Fake, allowing us to test methods which call the TestableRoleController.

We believe that this is a simple pattern which will encourage creation of Testable Controllers, and as we move closer to the 6.2 Release expect to see more of the core converted to this pattern. Of course, the existing methods will be retained for binary compatibility, but we are also taking the opportunity to clean up some of our old APIs.

Note: The usage of the TestableRoleController is temporary – ultimately RoleController will be refactored to inherit from the new ServiceLocator base class.

More ...

Tags: Testing,patterns,service location

Category: Development

DotNetNuke 6.2 CTP 1: Maximum Roles

Wed, 29 Feb 2012 08:00:00 GMT

DotNetNuke 6.2.0 removes the maximum roles limitation of previous versions.

Many developers are aware that, prior to version 6.2.0, a semi-colon delimited list of roles was saved in the user's cookie.

As the cookie has a fixed size, this effectively limits the number of roles to which a user could belong to about 50 (the actual limit depends on the names used for the roles – shorter role names would increase the maximum limit slightly).

Category: Development

DotNetNuke 6.2 CTP1: Page Hierarchies

Tue, 28 Feb 2012 08:00:00 GMT

DotNetNuke 6.2.0 introduces changes to how the Tab (Page) Hierarchy is managed.

Due to the limitations of earlier versions of SQL Server, which we were required to support prior to DNN 5.4, the business layer had to manage the handling of the page hierarchy. Whenever a page (tab) was created or moved in the hierarchy, there was a lot of calculation to calculate the effect on other pages and update them accordingly.

In a large site like this one - if a page with a large number of descendants is updated then every descendant is updated so that its "Level" and "TabPath" can be updated in the database.

DotNetNuke Patterns and Practices - 1: An Invitation to the Community

Fri, 17 Feb 2012 08:00:00 GMT

Welcome to a new series of blogs/articles on Patterns and Practices for development using DotNetNuke.

In this series I will be asking members of the Engineering Team at DotNetNuke Corporation and Community Members to contribute articles describing Patterns and Best Practices for DotNetNuke development.

Tags: patterns,practices

Category: Development

Look Mom – NoSQL!

Thu, 17 Nov 2011 00:04:31 GMT

Its been a while since I blogged here, but I recently started a new blog series on my personal blog on the topic of NoSQL databases.

Recently this topic and in particular a particular subclass of databases called “Document Databases” came up in a discussion the Product Team were having on proposed features for 6.vNext..

So I decided it was time to dive into this class of databases in order to find out if they could provide some benefit to us in the Medium to Long Term.

The topic is very technical so I don’t propose to reproduce every blog post here – but if you are interested in what I find out then feel free to visit my personal blog.

More ...

I’ll be speaking at DevReach

Sun, 18 Sep 2011 08:00:00 GMT

I am pleased to announce that I will be speaking at DevReach in Sofia, Bulgaria next month. This is the sixth year for this conference - which bills itself as the Premier Conference on Microsoft Technologies in Eastern and Central Europe - but its the first time for me.

Tags: devreach,Conference

Category: Events