DotNetNuke and Kentico are leading .NET-based CMS products. In this post, we do a detailed technical comparison of their core CMS architecture and also provide an overview of their broader digital marketing footprint.
The Technical Comparison Framework
We typically evaluate CMS capabilities using a framework outlined below. At the lower levels of the pyramid, product capabilities are mostly similar. The differences begin to emerge at the higher levels.
How a CMS manages content. This usually covers the following areas:
- Static Pages
- Dynamic Content Posts
- Custom Fields and content types
- Media and Asset Management
- Taxonomy of Categories and Tags
- Navigation Elements: Menus, Breadcrumbs and such
- Ability to handle all of the above in a multilingual setting
Workflows, Users and Permissions
How the CMS handles various workflows for publishing content and assets. Also the ability to create users with different roles and provide granular permissions.
Templates combine static and dynamic content with CSS styling and JS scripting to create pages on the fly. We evaluate the ease, power and flexibility of the templating engine that the CMS provides.
Modern websites involve blocks of content, styling and functionality that are reused on different pages. These are typically wrapped into “components” within the CMS. We evaluate the depth of a CMS’s capability in this regard. For a more detailed discussion on this topic, you can go here.
Personalization is the ability of a website to dynamically change what it shows to a user based on his context. This is usually an advanced capability of the CMS. For an introduction to this topic, go here.
Every CMS exists within a rich “app store” of products. The breadth and depth of this ecosystem varies significantly for different CMSes. We do a high-level survey to provide some indicators.
After we evaluate a CMS along these lines, we extend our analysis to the broader digital marketing footprint of the vendor. This includes the following areas:
- Audience Management
- Email Marketing and Campaign Management
- Marketing Automation
An Overview of the Technical Stacks
Workflows, Users and Permissions
Kentico allows you to organize and control the process of creating, updating and publishing pages on your website by applying workflow. It allows you to use workflows for all pages in the content tree of the Pages application. This also includes the files uploaded to the content tree.
The workflow support allows you to organize the process of content creation, updates and publishing on your website.
- Advanced workflow adds support of branching the workflow process based on macro conditions and user decisions. It also allows for automatic manipulation of the pages as they go through the workflow process.
- The versioning support is tightly bound with workflow and allows you to store, view and roll back previous versions of the content.
- Versioning without workflow creates a new version whenever a page is modified, while the whole editing process remains as if the page was using no workflow at all.
- The content locking (check-in/check-out) support allows you to avoid concurrent modifications of the same page by multiple users.
- The preview support allows you to see the content in the context of the site before it’s published. This feature is only available for pages that use workflow — you can preview the pages before switching them to the following step.
- The archiving support allows you to archive a page. Such a page is no longer displayed on the website, but it’s kept in the content tree and can be re-published at any time later.
DNN Workflow allows you to create a publishing flow that provides an approval process between when a user creates the content and when the content becomes live. DNN has built a few different workflow processes for the HTML and File Manager modules.
DNN provides Workflow Management through Evoq support. Evoq Supported workflow types are Direct Publish, Save Draft and Content Approval. Multi-phase workflows are also supported.
Workflow in a Custom DNN Module
In DNN 7.4 third-party module developers can tap into the same workflow mechanism and definitions. DNN introduced the Workflow API which allows custom modules to leverage the core workflow processes in their custom module.
Every page on a Kentico website, with the exception of pages based on content-only page types, is based on a page template. Page templates consist of a layout and instances of web parts and their definition is stored in the database.
The structure of each page template is determined by its page layout, which you can either define through full ASCX markup or standard HTML code. The code allows you to set up any layout that you require for your pages. Portal Engine page layouts need to contain special markup tags that define web part zones — areas where developers place web parts. Each web part zone can contain any number of web part instances.
A page is defined by the layout template, which comes with the theme installed for the site. The layout specifies where the panes go, and each pane contains a module. A module presents content, which could be static or dynamic.
Within DotNetNuke the term templating is used to mean a way that an object can be defined via a simple text file. These definitions can then be processed by DotNetNuke which can then take some action, in some cases adding data, in others formatting an output.
DotNetNuke provides support for templating at a number of levels.
- Portal templates — provide a way to define a new portal.
- Page templates — provide a way to define the default content of a new page
- User profile templates — provide a way to determine the layout and data used when showing a users profile details
Web parts (called “servlet”, “portlet” or “module” in other solutions) are components that display some type of content or provide background functionality. From a technical point of view, web parts are standard ASP.NET user controls with a predefined Portal Engine interface.
MVC widgets in Kentico represent reusable components that can easily be manipulated by content editors and other non-technical users. Widgets and the Kentico page builder feature give said non-technical users more power and flexibility when adjusting page content, in addition to basic editing of text and images. By working with widgets, users can decide which components are placed on pages and where.
Modules extend the functionality of the DNN framework. As DNN is architected in a modular fashion the term “modules” makes sense as a module represents a set of re-usable code that can be installed into any DNN site.
A typical web page includes page elements and content blocks. Page elements, such as the site menu, the login control, and the search bar, are included with the theme. Content blocks are managed by modules.
The module is one of the basic building blocks that extend DNN to enable users to view, create, and edit content. All DNN administrative features are implemented as modules.
Kentico provides two development models — Portal Engine and MVC.
Portal Engine allows you to build websites in a browser-based interface using components called web parts. The underlying architecture is based on ASP.NET Web Forms.
MVC: Kentico supports website development using ASP.NET MVC 5. This development model is based on a separate MVC application that handles the presentation of the live site, while the Kentico application serves as a content platform.
DNN provides three development models — MVC, SPA and Web forms.
MVC : The MVC module type integrates ASP.NET MVC 5 with the DNN platform. MVC modules can use any of the standard DNN module features. All DNN module types can co-exist on a single page, and the user should not be able to distinguish which framework was used to build the module.
SPA: Single-Page Application (SPA) frameworks are a newer alternative to server-side web development frameworks such as ASP.NET. SPA replaces the full-page updates of server-side frameworks, with small targeted updates of select page elements. This lightweight approach results in a faster and more responsive UI.
Web Forms: Web Forms modules follow the standard DNN module architectural pattern and use a traditional server-side rendering model. When a page is requested, DNN will create an instance of the relevant module control as defined in the module definition. The module control inherits from a code-behind class that contains the presentation logic and that makes additional calls to the appropriate business methods in the Business Logic Layer.
Digital Marketing Footprint
This article was first published on www.exemplifi.io