PostNuke Module Design

The PostNuke module system design has been carried out by the PostNuke development team to allow for the maximum flexibility to developers whilst ensuring that the module can be accessed in a generic fashion by the PostNuke core, other modules, and remote systems given access through other interfaces such as XML-RPC. The main design characteristics of the module system are listed below.

Separation of User and Administrator Functions

Separation of user and administrator functions allows for a much cleaner module. It speeds up the responsiveness of the module in the most-often used cases (i.e. user actions) as the module only needs to load the code that is required of it. It allows for work on one area of the code (e.g. an admin GUI redesign) to take place without affecting the other areas. And it also gives an extra layer of security to help ensure that privileged functions cannot be executed inadvertently from user areas.

Separation of Display and Operational Functions

Separation of display and operational functions allows for areas within and without PostNuke to use the functionality supplied with a module. This is most obvious in the case of modules with blocks, where the block might display its own information but use the module functions to gather that information. Other modules where this is hugely important are the utility modules; things like comments and rating systems, that have no real use on their own but can be coupled with other modules to provide generic and site-wide functionality at very little cost to the module developer.

Single Directory Installation

Having a single install directory allows for much easier maintenance of large PostNuke systems, and far easier installation and removal of modules both for the module developer and for the site administrator. Dependencies of the layout on the filesystem are no longer required, and as such the module designer does not need to worry about on which systems his module might be deployed, and how it needs to interact with the underlying operating system to function correctly.

External Access to Module Functions

Allowing access to module functions from external (i.e. non-PostNuke) systems is a very desirable thing to do. By allowing this, the PostNuke system becomes a content repository, where information can be accessed in ways other than through the standard web interface. An example of this power can be seen through use of the XML-RPC interface that is provided with PostNuke and which allows other systems to obtain information directly from modules without going through the web interface, thus allowing things like easy syndication of a site's content.