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 modules.

There are two basic ways of using Modules API:

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 module.

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 event.

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 module API.

See Also

© 2002-2008 Telerik. All Rights Reserved.