Adding Core Taxonomy to Your Module: Part 1 – Getting Started

In this blog series I will cover how developers can implement Taxonomy & Folksonomy in their own custom modules. Having spent the last few days trying to implement in my own custom module, I realized there is a lack of information on this subject available today which I found somewhat surprising (considering the demand for taxonomy integration into the core, which we finally received in 5.3). Hopefully, this blog series will help fill that void and soon module developers will be adapting core taxonomy in their own modules. In this blog entry, Part 1, I will cover what developers should know and consider prior to working on their own integration.

Before getting started you should read the background information on the core implementation of Taxonomy. To do so, please view the two blog posts done by Charles Nurse on this topic. Part 1 discusses the Core Taxonomy manager while Part 2 provides an overview of the data layer. While Part 1 of Charles blog provides some information any module developer should review, understanding Part 2 is critical for this blog series. I should also point out that my blog series will be focusing on Taxonomy and Folksonomy (as well as Content, which is required for Taxonomy/Folksonomy integration) and I will NOT be integrating MetaData. For a number of reasons I have decided not to cover MetaData but the primary one is that, currently, nowhere in the user interface of the framework is this exposed.

Now that you have some background on the core implementation, I should touch on a few things about my setup (and this series). First, I wanted to create a module (for my own needs) that utilized taxonomy/folksonomy but I wanted to approach this blog series without going through all the steps of creating the module. Therefore, I built the module and made it work prior to any integration of taxonomy/folksonomy which this series will assume you have done as well. Second, my module is a single module but it contains many Content Items (which we will cover later in the series, Part 2). What this means is it is like a forum, blog, or news module and contains multiple content entries within a single module instance (Ex. a forum would contain multiple threads, each thread being its own Content Item within a single forum module instance). Because of this, this series will focus on these type of modules with multiple Content Items within a single module instance (although it should be easy enough to adopt this to a single Content Item module scenario). Third, I found a few ‘quarks’ in using core taxonomy, all of which I logged in Gemini and should be fixed in a future version. Nothing I found was a show stopper for development but I will make note of any of my observations throughout the series if it affected a specific area I am covering.

Finally, the remaining things about my setup worth mentioning are:

1. My module is written in C#, although I will post code snippets in VB.NET as well (if applicable).
2. My module is built using MVP (Model View Presenter) style Module Development using the WebForms MVP project as a basis (I will cover the complete development of my module, minus taxonomy integration, in another blog series in the future).
3. I make use of nAnt for module packaging.
4. My module adheres to the DotNetNuke API 100% and does not use any third party libraries (outside of what DNN uses) that are not 100% open source.
5. My module is built against the 5.4.2 core version of the framework. You will definitely need to be using at least 5.4.0 in your own module but I recommend the newest release available on the 5.4.x path (or greater) for your development (due to bug fixes).

The last thing I think I should touch on here is the level of complexity (or lack thereof). Assuming you have a working module, the hardest part of the integration (for me, at least) was learning how to utilize taxonomy properly in the framework which is exactly what this series is covering. My guess is that after reading this blog series it should only take DotNetNuke module developers 2-6 hours to implement taxonomy in their own modules depending greatly on the complexity of their module (again, this is assuming the developer has a fully working module).

I know this is only a ‘teaser’ blog entry but it is critical to understand what I have here prior to diving into any specific development details (I also felt it was good to break the series up into small blocks of information). In the next part of the series I will be covering Content Items.