This topic provides explanation and guidelines on using the Modules API.
Sitefinity has fully exposed API and modules are no exception to this. Modules API is very useful when implementing additional functionality or combining two or more
There are two basic ways of using Modules API:
- Handling events fired by modules
- Working with module manager classes
Deciding on which way to use modules API ultimately depends on what are you trying to accomplish. If trying to execute some logic every time a module performs
certain action, handle the events fired by the module. If trying to provide some specific implementation of modules, work directly with the manager class of the
Handling Events Fired by Modules
Let’s assume that we have to implement a control that will list the latest 10 items (for example: news, blog posts, events) on the Web site. A simple way to achieve this
would be to combine functionality of the Lists module and the News, Blogs and Events modules.
We use the Lists module because we could take advantage of the Lists public control to display the newest items, and all of its built-in modes. Since
News, Blogs and Events modules are based on the Generic Content module we know that they expose certain static events and we are mostly interested in the
OnExecuted event. This event is fired every time a Generic Content based module has executed a command (like "ContentSaved", "ContentDeleted", and so on).
Let’s take a look at the following graph (Figure 1):
Figure 1 – Taking Advantage of Modules API in Sitefinity to Create New Functionality
If you look at the graph you will notice that it consists of six parts. Out of all of them, you need to develop only one: NewsItemsManager. Since
OnExecuted is a static event, we can subscribe to it from anywhere and it will get handled. So, to make things simple we can create a new NewsItemsManager class
and place it in the App_Code folder. There, we are going to subscribe to the static OnExecuted event that is exposed by all Generic Content based modules. Every time any
of the Generic Content based modules fires an OnExecuted event, we are going to check the CommandName and, (if CommandName is “SaveContent”) we are going to
use ListsManager class (API class of Lists module) to add new item to the list displaying newest items. Before creating a new list item, we are also going to
check if the list has ten items, and if so, delete the oldest item since our list should display only ten newest items. Finally, the Lists public control will display the
list of all items.
As demonstrated, we can combine several Sitefinity modules to work together and provide completely new functionality by simply creating one new class and handling one
Working with a Module Manager Class
Every built-in Sitefinity module has a manager class. The naming convention of these classes is very consistent. For example, the Blogs module has a
BlogManager class, the Events module has EventsManager class, the Lists module has ListManager class, and so on.
These classes are a point of access for any data-related work, though they don’t work directly with data. Any manager class can be instantiated with a provider name.
||If an empty constructor is used, classes will be instantiated with the default provider.
Once instantiated, the manager class will use the appropriate provider to perform actual data manipulation. For example, the BlogManager
class exposes the public method DeleteBlog(Guid id). You can call that method and pass it the id of the blog to be deleted from anywhere inside of your
application. The manager class will then call DeleteBlog(Guid id) method on the actual provider which will delete the specified blog from the data storage. The reason for this
middle layer is quite simple. Let’s assume you have developed several controls that use the BlogManager class and its members. Now that all the work is done, you decide to
store data in XML files instead of SQL Server. All you have to do is implement XML provider for the Blogs module. Your controls will still call the BlogManager class and its
members, but they will instantiate the BlogManager class with the name of your XML provider. So, without any modifications on the controls you have developed you are able to
change the data storage for BlogsModule. This is the main reason why we don’t encourage developers to program directly against database.
When talking about built-in Sitefinity modules, it is important to note that manager classes expose publicly all methods and functions needed for the modules to work. The modules
you are using everyday are built exclusively using the manager classes, and you have access to these classes as well. All the CRUD methods are fully accessible through the