Sitefinity 3.6 new backend architecture - What has changed, what hasn’t?

[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]
 

So far, we were talking a lot about the new backend architecture introduced in Sitefinity 3.6, so one may easily come to the conclusion that we have changed absolutely everything there is to be changed about developing modules in Sitefinity. In order to bring some clarity to this issue, let’s examine first the list of things that have changed in the new Sitefinity 3.6 backend architecture, and then we’ll take a look at the list of things that have stay unchanged.

 

What has changed?

• ControlPanel class
  Modules used to inherit from Telerik.Web.ControlPanel base class when implementing Control Panel classes. In Sitefinity 3.6 you should inherit from Telerik.Cms.Web.UI.Backend.ControlPanel<T>  base class, or if your module is going to support multiple providers from Telerik.Cms.Web.UI.Backend.ProviderControlPanel<T> base class.
• CommandPanel class
  Modules used to implement CommandPanel class by inheriting from Telerik.WebCommandPanel base class, while in Sitefinity 3.6 this has been changed to Telerik.Cms.Web.UI.Backend.CommandPanel base class. As a side note, starting with Sitefinity 3.6 you are not obligated to explicitly implement CommandPanel class anymore, since it is built in ControlPanel base classes and you can simply populate it’s collection of commands. However, you are still free to implement your completely custom implementation of CommandPanel class and add it to the collection of CommandPanels.
• GlobalPermissions class
  In the previous versions of Sitefinity, GlobalPermissions class used to implement ISecured interface. In Sitefinity 3.6, GlobalPermissions class should inherit the SecuredBase abstract class. This is enforced by some changes in the security model.
• Postback model for changing modes of the Control Panel
  In prior versions of Sitefinity one used to perform a postback every time when Control Panel should change mode (for example from list of news items to editing a news item). Starting with Sitefinity 3.6 and new backend architecture, this is now done by navigating between views. API methods and functions for creating commands and navigating to commands have been implemented on the base ViewModeControl classes which eases this process furthermore.
• The way template are instantiated
  In Sitefinity 3.6 base ViewModeControl class has assumed most of the responsibility when it comes to instantiating templates. ViewModeControl class will according to its internal priority system load template declared inline, in the LayoutTemplatePath property, declared as an embedded template or mapped from ControlsConfig file. There are no more DefaultTemplate classes.
• GenericContainer class
  Prior to Sitefinity 3.6 we used to have practice to instantiate templates in classes of type Telerik.Cms.Web.UI.GenericContainer<T> which would then provide strongly typed access to child controls of the template. In the new backend architecture this class has been replaced with Telerik.Cms.Web.UI.GenericContainer which is declared as property on the base ViewModeControl and initialized automatically for us. The child controls are now recommended to be declared as virtual properties of the class that uses them which allows inheritor to modify their necessity as it sees fit (for example, base class may declare property as required control, while derived class may override that property as optional control and remove it then safely from template).

What hasn’t changed?

It is important to note that the changes introduced with Sitefinity 3.6 mainly concern the composition of the presentation layer. Along these lines we can conclude that manager classes, provider classes and other layers of typical modules have stayed unchanged.

 

Let’s take a look at the list of classes that have remained unchanged:

• Module classes
• Provider configuration
• The way public controls are being declared for the module
• Manager classes
• Provider classes

With this article, we are pretty much wrapping up the introductory part of this topic and in the next article we are going to take an architectural overview of the new backend architecture - which will allow us to start talking on a more practical level.