Designing extensible modules - best practices: Overview

Designing extensible modules - best practices: Overview

April 07, 2009 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

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

 

Most of the time, you as a developer, will be developing end user modules that have a very specific purpose. On the sample modules provided in the documentation we have demonstrated various approaches for this kind of development.

 

However, from time to time, you will see that you keep developing very similar modules that vary only in details. The example of such module is Sitefinity Generic Content module. When you recognize such pattern, it makes sense to abstract all the commonalities and design one extensible module that could be easily reused across many similar modules.

 

In this topic of the manual, we are going to explore the subject of designing extensible modules. As a reference we are going to use built-in Generic Content module.

 

The View independence


In this topic we will not concentrate that much on the data persistence or the API of our module, but rather on the Views as single units of functionality. It is our goal to design a module which consists of Views which can:
  • Have any other View as their Host
  • Be located anywhere in the Views hierarchy
  • Can have different set of child controls, depending on the module in which they are implemented
You will see that all this becomes much more straightforward if we design Views that do only one single thing (e.g. edit content).

 

By designing Views in such manner we will be able to take any given View from our extensible View and use it in other module with little or no effort. Since we never know in advance where the little modifications might come, we will design every View very flexibly so that the inheriting module can change pretty much any aspect of the base View, while reusing everything else.

 


Conclusion


Articles in this topic are of a more advanced nature and if you do not have plans for the design of such modules, you may feel free to skip them. The audience that may find this topic very helpful are 3rd party developers for Sitefinity as well as solution providers which work on a large number of projects.

progress-logo

The Progress Guys

View all posts from The Progress Guys on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments
Comments are disabled in preview mode.
Topics
 
 
Latest Stories in
Your Inbox
Subscribe
More From Progress
d12fcc0bdb669b804e7f71198c9619a7
5 Questions Automakers Should Ask to Improve Asset Uptime
Download Whitepaper
 
SF_MQ_WCM
2018 Gartner Magic Quadrant Web Content Management (WCM)
Download Whitepaper
 
What-Serverless-Means-For-Enterprice-Apps-Kinvey
What Serverless Means for Enterprise Apps
Watch Webinar