Module: OpenStar Generator
Description: Le générateur de module d'OpenStar est destiné pour produire automatiquement un module fondamentalement fonctionnel avec des caractéristiques minimales. Ce processus peut vous permettre de gagner (littéralement) des jours de travail en effectuant le travail le plus pénible et pour vous.
Veuillez noter que le générateur de module lui-même n'est pas disponible en téléchargement ; il est disponible en utilisation comme service à la communauté.
Lien du générateur de module: OpenStar Generator.
Support:Forum.
Indépendamment du type de module que vous choisissez de produire, le générateur de module d'OpenStar réalisera toujours les dossiers globaux suivants pour vous (énuméré dans l'ordre dans lequel ils sont employés par le module) :

• pnversion.php
  
• pntables.php
  
• pninit.php
  
• pnadmin.php
  
• pnadminapi.php
  
• pnuser.php
  
• pnuserapi.php
  
• pntemplates/eng/admin.php
  
• pntemplates/eng/user.php
  
• pntemplates/eng/common.php
  
• pntemplates/deu/admin.php
  
• pntemplates/deu/user.php
  
• pntemplates/deu/common.php
  

En plus des dossiers globaux énumérés ci-dessus, le générateur de module OpenStar produira les calibres (templates) suivants de pnRender pour chaque type d'objet (OT) :

• [module]_detail_[OT].html
  
• [module]_form_[OT].html
  
• [module]_view_[OT].html

Si vous générez un module PostNuke, vous pourrez initialiser le module par l'intermédiaire des équipements standard d'admin de module de PostNuke. Une fois que le module est initialisé (ce qui implique que les tables aient été créées), vous serez capable de faire appel aux fonctions principales d'utilisateur du module, détailler, éditer et visualiser aussi bien que la fonction principale et les préférences d'admin. Vous devrez alors personnaliser plus loin les générateurs de template, terminer les fichiers de langage et écrire votre propre persistance de base de données (IE : fonctionnalité de lecture/écriture de base de données).

Si vous choisissez de générer un module OpenStar, le module générera des implantations de composant/classe (qui manipulent la persistance de base de données) pour vous, ayant pour résultat un module qui peut sauvegarder et charger des données de forme/objet automatiquement à la base de données. Soyez conscient svp que ce module réalisé ne fonctionnera pas sur une installation standard de PostNuke. Vous avez besoin d'une installation compléte d'OpenStar ou d'une installation de PostNuke avec le patch d'OpenStar v4blib appliquée pour ce module afin qu'il fonctionne. Ce mode de génération produira les dossiers additionnels suivants dans le dossier des classes du module pour chaque type d'objet (OT) :

• V4B[OT].class.php
  
• V4B[OT]Array.class.php

Dans ce cas-ci, le module a la même possibilité de personnalisation supplémentaire qu'un module standard de PostNuke mais la persistance (IE : la fonctionnalité de lecture/écriture de base de données) sera mise en application par les fichiers générés de classe. Dans ce cas-ci vous avez un module entièrement fonctionnel qui supporte tous les aspects d'un modèle "1-page-to-1-object-type" standard. Si c'est toute la fonctionnalité standard dont vous avez besoin, ce que vous devez tout faire maintenant c'est une personnalisation d'entrée. En outre, puisque les bibliothèques de développement d'OpenStar sont intégrées dans PostNuke (et seront disponibles avec la version 0.8) il y aura un chemin de migration pour les modules OpenStar-spécifiques (nouvelle) vers l'architecture de PN. Ceci signifie que si vous générez un module OpenStar, vous pourrez convertir ce module par l'intermédiaire d'un script pour correctement fonctionner avec la version 0.8 de PostNuke.

Comment cela fonctionne-t-il ?
C'est en fait très facile. Vous avez 3 champs d'entrés :

• Nom du Module : Entrez le nom du module que vous voulez générer (ie: GameScores, SportsTeams, Inventory, etc.)
  
• Type de Module : Choisissez si vous souhaitez générer un OpenStar prolongé ou un module standard de PostNuke
  
• Données de Tableau : c'est ici que vous saisissez vos données de table, voyez l'explication ci-dessous

Le champ d'entrée de données de Tableau est le seul assez délicat a réaliser, ainsi il sera expliqué en détail ici : La zone d'information de table exige une représentation de texte complet (plaintext) de vos tables de données dans le format suivant :

table1|table1_column_prefix
column1|sql_type|field_type
column2|sql_type|field_type
...

table2|table2_column_prefix
column1|sql_type|field_type
column2|sql_type|field_type
....

Des Tableaux sont séparés par un interligne et des champs sont séparés par le symbole a |. Cette syntaxe simple donnée, une définition valide pour 2 simples tables serait

COMPANY|cmp_
id|INTEGER UNSIGNED NOT NULL AUTO_INCREMENT|H
type_cat_val|VARCHAR(64)|L
name|VARCHAR(80)|S
sortname|VARCHAR(80)|S

COMPANY_BRANCH|brc_
id|INTEGER UNSIGNED NOT NULL AUTO_INCREMENT|H
type_cat_val|VARCHAR(64)|L
name|VARCHAR(80)|S
sortname|VARCHAR(80)|S

Le troisième champ sur les lignes de spécifications de champ (le champ type de champ) peut avoir les valeurs suivantes :

• C: Checkbox
  
• D: Date Selector
  
• H: Hidden Field
  
• L: Selector
  
• S: String Input
  
• T: Textarea

Attention !
Ce module de génération de module est réellement un hack surdimensionnée. Il n'a pas été écrit pour être particulièrement robuste ou futé. Si vous alimentez l'entrée incorrectement ou de manière absurde, il se produira heureusement un module non fonctionnel en utilisant cette entrée. Cependant, quand l'entrée donnée est correcte,vous obtiendrez un module fonctionnel. Ainsi si vous produisiez un module et que ce dernier ne fonctionne pas, il y a de grandes chances que l'entrée soit incorrecte. Étudier tous les messages d'erreur que le module produira, ce qui mènera habituellement à l'entrée en cause.

En outre, puisque n'importe quel module produit avec cet outil aura besoin de davantage de personnalisation, il est relativement important de penser à votre structure de données avant de produire un module et de l'adapter à vos besoins. Il n'y a rien de plus ennuyant que de découvrir après quelques jours que la personnalisation de la/les structure(s) de données que vous avez commencé sont insatisfaisants et nécessite des changements étendus.
Dans ce cas vous pouvez réaliser un hack (et adapté aux besoins) du module produit pour refléter vos besoins de nouvelle/changé ou régénérer le module avec des entrées de nouvelle/changé et puis fusionner vos changements de personnalisation en module nouvellement produit. Ni l'une ni l'autre de ces actions n'est vraiment amusante, faite donc une planification pour l'avenir.

Pour finir, si vous n'êtes pas un programmeur qui connait le PHP et les modules de PostNuke, quoique on applaudit de tout coeur votre résistance (de lecture) en ayant atteint ce point, la vérité est que ce module ne vous sera pas beaucoup utile.