Choisissez le nom de votre module
        Décidez du type de votre module
        Enregistrez le nom de votre module
        Comprennez les secteurs suivants
            Différence entre GUI et les fonctions d'opérations
            Différences entre les fonctions utilisateur et d'administration
            La sécurité avec PostNuke
            les valeurs de retour des fonctions
            Comment ajuster les modules
        Concevez votre module
        Incluez des fonctions standards
        Utilisez des noms de fonction standards
            Fonctions d'affichage pour les utilisateurs
            Fonctions API utilisateur
            Fonctions d'affichage pour l'administration
            Fonctions API pour l'administration
        Découvrez les modules de service utiles

Choisissez le nom de votre module

Le choix du nom de votre module est extrêmement important. C'est le premier pont entre votre module et la communauté postnuke. Le nom doit être lié à la fonctionnalité du module. Mais soyez assez spécifique pour éviter qu'un autre module ayant des fonctionnalités simmilaires aie le même nom.

Les noms de modules sont sensibles à la casse (MAJUSCULES/minuscule). Il est toutefois recommandé de créer votre module en minuscule.

Décidez du type de votre module

Il y a deux types principaux de modules. Les modules types 'articles' sont des modules qui gèrent un contenu et utilisent/transforment ce contenu (ex: FAQ, download). A l'opposé, les modules 'utilitaires' permettent d'ajouter des fonctionnalités aux autres modules (ex: EZComments, rating). Les modules utilitaires peuvent gérer un contenu et permettent d'améliorer des fonctionnalités d'autres modules (Hooks).

Enregistrez le nom de votre module

L'enregistrement de votre module n'est pas obligatoire, mais c'est une très bonne idée de le faire. En enregistrant votre module, vous pouvez vous assurer qu'aucun autre module officiel de PostNuke ne prendra le nom que vous avez choisi pour votre module. 2 modules ne peuvent avoir le même nom. Ou alors PostNuke ne pourra pas fonctionner de manière correcte. En enregistrant votre module, vous pouvez être certain que personne ne pourra prendre le nom que vous avez choisi pour faire un module distribuable.

Plus d'informations ici: http://news.postnuke.com/index.php?module=Static%20Docs&func=view&f=/pnModulereg.htm

Comprennez les secteurs suivants

Différence entre GUI et les fonctions d'opérations

Comprendre la différence entre GUI et les fonctions d'opérations est important pour construire un bon module. La séparation appropriée de ces fonctions permettra à d'autres modules de pouvoir accéder à la fonctionnalité de votre module et de l'incorporer à leur module. Il permettra également à des méthodes d'accès indépendamment de ceux du système PostNuke d'accéder aux informations.

Différences entre les fonctions utilisateur et d'administration

La différence entre ces deux fonctions est importante. les fonctions d'administrations ne sont accessibles qu'aux administrateurs et les fonctions utilisateurs permettent d'accéder aux fonctionnalités du module: ce pour quoi il a été concu.

La sécurité avec PostNuke

La sécurité lors de la création d'un module est un point sur lequel il faut faire attention lors du codage de votre module. Les développeurs doivent comprendre quelles parties de leur module doivent être protégées et de quelle manière.

les valeurs de retour des fonctions

Les fonctions contenues dans les modules doivent toujours retourner une valeur de retour appropriée. Les valeurs de retour sont les seul liens entre le module et le coeur de PostNuke. C'est pourquoi il est vital de bien les écrires et de bien les utiliser. Les codes de retour doivent être utilisés pour toutes les fonctions PostNuke.

text string Retourn une chaine de caractère correspondant au texte approprié demandé par la page. PostNuke récupérera le texte et l'affichera. Postnuke se chargera de récupérer le contenu et de l'afficher. Ce contenu doit contenir la mise en forme spécifique de la fonction.

true le booléen true indique que la fonction à finie son travail et définit une redirection pour envoyer l'utilisateur sur une page qui a une sortie d'affichage. Le noyeau de PostNuke ne prendra aucune autre mesure en ce qui concerne ce module.

false Returning boolean false implies that the module function has finished its work but not set up an appropriate redirect to send the user to a page that will have display output. The PostNuke core will set an appropriate redirect for this module.

Note that none of these functions carry any information about the success or failure of the attempted operation that the module function was undertaking.

Comment ajuster les modules

Modules cover two separate areas of PostNuke. The first is administration of core functions, (e.g. users, permissions), and the second is extension of system functionality (e.g. downloads, web links). As each of these areas are not core this implies two things. First is that no module is actually required - the PostNuke system would work without anything in its modules directory, although its functionality would be severely limited and there would be no configuration options available. Second is that modules should not remove any core functionality when they are installed, operated, or removed.

Concevez votre module

An often overlooked point is that the module should be designed before being coded. This will allow for far easier coding later on, and an understanding of how the module fits into the generic PostNuke module structure. Some of the points that should be considered are:

-->What data does the module store? How should the module data best be stored? Is the data hierarchical or flat?
-->What does the module do with the stored data? How is the data displayed, how much data is displayed at any one time? What options should the user have to view the data in different ways?
-->How does the module interact with other modules? Does it compete directly with other modules? If so, does it make sense to follow their module API to allow for greater interoperability between similar modules? Can it use other modules for part of its functionality? Is it better written as an extension to a current module rather than starting again from scratch?

Incluez des fonctions standards

There are a number of standard module functions that allow a newly written module to interface with other parts of the PostNuke system. These functions have predefined inputs and outputs, allowing external modules and core functions to use them effectively without needing to tailor their operation to each separate module. The best example of these functions is the 'search' function, which passes in a simple text string and requires that an array is passed back about all items within the module that match the string.
Note

Clarify the search function

If your module does not have these functions then it will not integrate fully with the other parts of the PostNuke system. It is recommended that these functions are supplied if they make any sense in the context of your module.

Utilisez des noms de fonction standards

There are a number of function names that are considered standard i.e. they have well-known meanings and are used in a number of modules. Using the standard function names makes it easier for other module developers to use your module. Some of the standard functions are shown below.
Note

The below list is subject to addition as more standard functions are introduced - the template module supplied with your copy of PostNuke should have the most up-to-date set of standard functions available.

Fonctions d'affichage pour les utilisateurs

main() - the default function to call, normally just presents the user menu
view() - display an overview of all items, normally paged output
display() - display a single item in detail, given an identifier for that item

Fonctions API utilisateur

getall() - get basic information on all items, can take optional parameters to obtain a subset of all items
get() - get detailed information on a specific item

Fonctions d'affichage pour l'administration

main() - the default function to call, normally just presents the user menu
view() - display an overview of all items, normally paged output, with relevant administrative options. Note that it is possible to combine this function with the user view() function
new() - display a form to obtain enough information from the user to create a new item
create() - take the information from the form displayed by the administration new() function and pass it on to the administration API for creating the item
modify() - display the details of a current item given the item description, and present the relevant fields for modification
update() - take the information from the form displayed by the administration modify() function and pass it on to the administration API for modifying the item
delete() - display confirmation for deletion of an item, and if confirmed pass the relevant information on to the administration API for deleting the item
modifyconfig() - display the details of the module's current configuration, and present the relevant fields for modification
updateconfig()// - take the information from the form displayed by the administration modifyconfig() function and update the relevant module configuration variables

Fonctions API pour l'administration

create() - create a new item
delete() - delete a current item
update() - update the information about a current item

Découvrez les modules de service utiles

There are a number of utility modules available to carry out features that are required by many item modules within PostNuke. Examples of available utility modules are comments, ratings, and categorisation. Take a look at mods.postnuke.come to find out what other utility modules are available and if they can be used in lieu of parts of the code that you would otherwise be writing for your own module.
Note

Point to a repository of utility modules and functions.