Sitefinity CMS

Modules Overview Send comments on this topic.
See Also
Sitefinity Building Parts > Modules > Modules Overview

Glossary Item Box

This topic provides an overview of modules in Sitefinity.

 

Modules are small, independent applications that provide Sitefinity with specialized functionalities. Sitefinity comes with several built-in modules, such as News, Events, Images & Documents, and so on. Sitefinity can be extended through new, custom modules, as well as extended by modification of existing modules. It is therefore very usefull to be familiar with the basic structure of every Sitefinity module – built-in or custom one - before working with Sitefinity.


Take a look at the following diagram (Figure 1) for a high-level overview of the module architecture:

Modules Architecture Overview

Figure 1 – Typical Architecture of a Sitefinity Module

 

Every Sitefinity module consists of two major parts: Admin side and Public side. The Admin side is the administrative part of the module, located in the Sitefinity administration area. This part of the module is typically used by content editors and users with access to the Sitefinity administration area. The other part of the module is the Public side. On that side, modules have one or more public controls which are placed on pages and site visitors can see them and optionally work with them (if public controls support user input). To clarify this first separation, let’s take Blogs module as an example:

  • On the Admin side, users can create new blogs, write blog posts, work with tags, categories, comments, and so on.
  • On the Public side, visitors can read blogs (through BlogPosts control) and leave comments (through CommentsList control, which is integrated in the BlogPosts control).

Figure 1 shows that both sides of a module consist of three different layers (presentation layer, business layer and data layer). While this separation is not necessary, we are strongly encouraging this approach and advocate it as the “best practice”. Apart from that, both sides of a module can take advantage of Sitefinity API, services, security and the personalization framework.

 

Admin Side

On the admin side, the presentation layer consists of two controls: Control Panel and Command Panel. Control Panel is the area on the right, while Command Panel is the area on the left.

 

Modules Overview - Administrative Side

Figure 2 – Module Admin Side: Command Panel & Control Panel


Control panel is used as the main work area for a module, while Command Panel generally holds only shortcuts to different functionalities of the Control Panel. Figure 2 shows Command Panel and Control Panel for the News module. Note the links in the Command Panel that lead to various views of the Control Panel (“News items”, “Categories”, “Tags”, “Permissions”), while on the right side, in the Control Panel, the actual data is displayed (Figure 2 shows a list of all news because the "News items" link was chosen).

 

Public Side

While content editors can work with data (such as news) in the admin side, the final goal is to present this data to the site visitor. This is achieved through the public side of a module or more precisely - public controls. In the previous paragraph we have examined the admin side of the “News” module, so let’s see how the public side of the “News” module looks like (Figure 3): 

Modules Overview - Public Side

Figure 3 – Module public side: public controls


Figure 3 shows the public side of the News module. To function properly, the news module implements two public controls: News View and News Archive. Everything that is created by the content editors on the admin side will be presented to the site visitors through these two controls.  Any Sitefinity module can implement any number of public controls on the public side to provide needed functionality for the visitors.

 

Business & Data Layers

Just as all other parts of Sitefinity, modules are built on the Provider model pattern. Figure 1 shows how both the admin and public sides use the Manager class (business layer) which then accesses the Provider class (data layer). While this is not an absolute requirement, implementing this pattern is highly recommended.

For more information on the Provider Model and its implementation in Sitefinity, see Provider Model.

 

Taking Advantage of Sitefinity API

Figure 1 also shows possible connections to the Sitefinity API from both sides of the module. Once again, let’s take News module as our sample module. As illustrated on the figure, both admin side and public side can connect to API (for exmaple, News View control can query Blogs module for blog posts related to the news item). On the public side, News RSS control can be implemented which would take advantage of the RSS service. Similarly, Command Panel (on the admin side) could restrict showing some of the links for which the currently logged-in user does not have permissions. Finally, by taking advantage of the personalization framework, Control Panel could display only the last 5 modified news items by the currently logged-in user.

 

Pluggable and Intra-site Modules

Sitefinity supports two kinds of modules: Pluggable and Intra-site modules. Both kinds of modules are able to provide the exact same functionality – the difference is only in the way they are developed and maintained.

  • Pluggable modules are compiled into assemblies, and are therefore a bit more complicated to develop - all controls must be developed as custom – composite controls. The advantage of this approach is that modules can be deployed as single .dll file which makes them perfectly suitable for distribution (across multiple sites or even as commercial modules).
  • Intra-site modules are developed through series of user controls and several classes in the App_Code folder. While much easier and quicker to develop, intra-site modules are much more difficult to distribute and maintain (unless they are running on a single installation of Sitefinity).


The rule of a thumb is that intra-site modules should be used only for one-time projects, when there is no foreseeable need for distribution of a module across multiple installations. On the other hand, when module is being developed as a commercial module or there is a great chance that the module will be distributed across numerous Sitefinity installations, this module should be developed as a pluggable module.

See Also