PostNuke Help |
||
|---|---|---|
Previous |
Next |
|
PostNuke is an alpha product and very much a work in progress. There are a number of areas that are currently still under redesign, and when the redesign and resultant new code is in place module developers will need to change their code to be able to support the latest functions. Any change of these areas will have at least one full release cycle where both old and new style code is supported so the transition period will always be a matter of months. All efforts will be made to keep the changes as simple as possible.
Areas that are still defined as to be upgraded before the 1.0 release are as follows:
The multilingual system. The current multilingual system uses defines, which does not lend itself to high levels of flexibility. This will be solved through some sort of functional interface into the multilingual system, although the details are yet to be defined. The change should involve developers replacing their current _LANGUAGE defines with function calls but should be a relatively simple search and replace operation without changing any logic within the modules.
The theming/templating system. The theming and templating systems within PostNuke are currently very basic and nonexistent, respectively. A number of PostNuke developers are looking at a much more flexible solution to display content. The change will probably involve developers reworking the display part of their modules, although it is hoped that one of the advantages of the new system is that it will make the entire work of displaying content to users less of a developer task and hence the re-worked code will be a lot simpler than the current display functions.
The hooks system. The hooks system is very new to PostNuke, and it is already recognised that it will require some extra work. The most obvious addition is to allow hooks access to module content, but others might be required as well. This should require minimal changes to development modules, but developers should be aware of this up-coming change both when using and coding hooks.
This document gives a step-by-step guide to creating a module for the PostNuke system. It covers all stages from the initial design and registering yourself with the PostNuke community to deploying, certifying, and upgrading your module.
Other documents that might be of use in conjunction with this guide are the API Command Reference, the Theme Development guide, and the Output Functions Guide. Note that the Theme and Output guide remain unwritten at this point.
The PostNuke module system is a work-in-progress. There are no doubt many good ideas out there that have not been incorporated into the PostNuke module system, and if a developer has a request for a particular set of functionality then they can submit it to the PostNuke features request list on SourceForge at the PostNuke Homepage. If you have found a bug within the current module system then you can submit it to the bug list at the same address.
Please note that the main requirement for the PostNuke module design is stability. Due to this it is possible that your request for new or updated functionality will get refused on the grounds that it is too specific, can easily be built from core API functions, or carries out work that should rightly be done by a module. In such situations the PostNuke team will always try to provide a simple alternative, but please remember that submission of a new or updated addition to the module design does not guarantee inclusion.
Previous |
Next |