Sitefinity CMS
Contents
Bare-bones Pluggable Module - Explained Send comments on this topic.
See Also
Developing with Sitefinity > Modules > Adding New Modules to Sitefinity > Pluggable Modules > Bare-bones Pluggable Module - Explained

Glossary Item Box

This topic provides basic implementation of a pluggable module with only the necessary classes and interfaces. Along with the explanation, you can download the Visual Studio template and use it as a starting point for your own pluggable modules.

 

Take a look at the following scheme (Figure 1) to see what classes and interfaces form a basic pluggable module and what their relationship is:

Pluggable Module - Explained

Figure 1

 

  • Module.cs
    Every module has a main module class. In our example, this is Module class. For example, in the Blogs module this class is called BlogsModule. While you are free to name this class any name you want, it is a convention with Sitefinity modules to name the class after the module. This class will define some basic properties of the module but will also register the admin controls (ControlPanel and CommandPanel classes) and any public controls that the module implements.
  • Admin controls
    There are two admin controls that you need to implement when developing a pluggable module with Sitefinity:
    • CommandPanel
    • ControlPanel

    Take a look at the following screenshot to see Blogs implementation of CommandPanel and ControlPanel controls compared to bare-bones module implementation of CommandPanel and ControlPanel:

    Pluggable Modules Explained - Blogs Implementation

    Figure 2 


    As you can see, CommandPanel is the control on the left in the admin side of the module. Its primary use is it provide various commands that will affect ControlPanel (such as change mode of the control panel). On the other side, we have ControlPanel control. This is the work area for your module and it is here that all the functionality will be implemented.

  • Public controls
    Your modules will surely have public controls - the ones that users will be able to drag and use on pages. This bare-bones module has only one public control, named PublicControl which is registered with Sitefinity in the Module class. Obviously, there is nothing stopping you to add more controls to this module.
  • Manager
    Every Sitefinity module has a manager class, which is basically the module’s API class. Since Sitefinity modules are built on top of provider model pattern, we strongly encourage you to build your modules using the same pattern. The basic idea of the manager class is that it can work with multiple providers (in effect with different data storages) without the need to change the rest of the code (like your controls).
  • ConfigHelper and SectionHandler
    The purpose of these two classes is to give you easy access to the module’s configurations in the web.config file
  • BaseModuleProvider
    Abstract class defining the methods and functions which must be implemented by any class that wishes to serve as provider for bare-bones module (such as DefaultProvider class)
  • DefaultProvider
    DefaultProvider is an actual provider implementation for bare-bones module. It inherits BaseModuleProvider class and implements abstract methods and functions. Provider implements the actual work with data (typically CRUD methods).
  • IData
    IData is the interface that represents data entity of bare-bones module. Typically, modules have more data entities and hence more interfaces (for example, BlogsModule has IBlog, IContent, ICategory, IComment, …). The manager and provider generally exchange interfaces of data entities, rather than the actual data entities. This provides for the flexibility in the future if the data storage or data layer implementation is changed.

 

The providers in this sample are in the same assembly as the module itself (in other words there is no Module.Data assembly), while the majority of our modules have module and data assemblies separated. The reason for this separation is that Telerik RadControls (used in module assemblies) cannot work with Nolics.NET (used in data assembly) under medium trust support, unless they are separated into two different assemblies. Therefore, we have separated all our modules in different assemblies. If you are not planning on using Nolics.NET as your data layer, there is no reason to separate module and data into two assemblies.

See Also