Content Items were introduced to the DotNetNuke core in version 5.3.1. These gave us the ability to start using taxonomy (categories) and folksonomy (tags) within DNN. The problem was the original version of this code was barely touched, if at all, from it’s initial release until around 6.2.4 when it was finally revisited to fix some crucial usability issues.
Today with DNN 7.0.2 many of the flaws with Content Items have been resolved and the API works as you would expect.
If you’re a module developer today then you’re probably either inheriting the old Data Access Layer (DAL) or maybe you realize that less that 1% of the DNN population is using anything but MS SQL as their database so you’ve adopted the DAL+. You may have even jumped to the cutting edge and embraced the new DAL 2 (PetaPoco). While I appreciate the DAL 2 functionality and promise of reducing my CRUD operations along with not having to create a multitude of stored procedures you’re still left with one crucial problem. Your data is in a silo!
The whole point of a Content Management System (CMS) is to MANAGE YOUR CONTENT. I can’t emphasize this point enough and I will likely bring it up repeatedly in the future. This is a core fundamental that makes a CMS what it is. DotNetNuke originally held this philosophy when it came to pages and files. But it loses when it came to module data.
Think about how much of a mess it would be if every single module had it’s own file library. You had to upload a picture multiple times because it wasn’t available from one module to the next. Why does this have to be any different for any other piece of content?
Why You Should Consider Using Content Items
For starters you don’t have to create any tables or write any stored procedure which means no more .SqlDataProvider files or updates to the DNN Manifest file when you release a new version. By using the same API to add,update,insert, and delete your content you don’t have to replicate these processes in all your modules
Secondly it allows you to pull in content that may not have been created by your module. Using these APIs you can pull in items from the module, page, or entire portal from one command.
Putting all your content into content items, even if you still want to house it elsewhere in your own tables, still gives the functionality of tagging and categorizing your content that can be consumed by other modules.
It still needs some love
DotNetNuke core still has some work to do to make this functionality more robust. As of DNN 7.0.2 Content Items still don’t have a caching layer. The search indexer still does not utilize the indexed flag built into the ContentItem entity. Additionally I think it should allow you to set a meta data property value equal to an entity object and it would automatically serialize that object during save and update methods.
Using Content items gives control back to the system administrators to use their content how they want. Ways we haven’t considered or want to invest time into. Furthermore it allows modules to work together as a structured unit instead of independent data warehouses.
Want to learn more about Content Items in DotNetNuke? Follow this blog and I’ll be be covering the topic more in depth in future posts. Until then you can also check out Chris Paterra’s post – Adding Core Taxonomy To Your Modules or checkout the code yourself.