Veremap.pro

Transcription

Veremap.pro
Veremap.pro
Module - Guide du développeur
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 1/18
Table des matières
1. Préambule ................................................................................................................... 3
2. Le contenu d’un module............................................................................................. 4
2.1 Le stockage du code source.................................................................................................... 4
Veremap.pro .............................................................................................................................................. 4
Veremap.admin ......................................................................................................................................... 4
2.2 Les fichiers aux noms génériques.......................................................................................... 4
Les fichiers PHP ........................................................................................................................................ 5
Les fichiers JavaScript............................................................................................................................... 7
Les fichiers CSS ...................................................................................................................................... 11
Les fichiers admin ................................................................................................................................... 12
2.3 Les fichiers d’installation..................................................................................................... 12
2.4 Arborescence d’un module « type » .................................................................................... 14
Code source du module ........................................................................................................................... 14
Localisation du code source après installation ........................................................................................ 15
3. Le fonctionnement d’un module...............................................................................17
3.1 La base de méta données...................................................................................................... 17
3.2 Les interactions application - module ................................................................................. 17
Lors du chargement de l’interface utilisateur .......................................................................................... 17
Lors du chargement de l’interface d’administration................................................................................ 18
Lors de l’utilisation du module................................................................................................................ 18
Schéma récapitulatif ................................................................................................................................ 18
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 2/18
1. Préambule
L’application Veremap.pro est conçue pour intégrer des modules. Ces modules peuvent être développés sans
impacter le code source du noyau de l’application.
Cette possibilité offre plusieurs avantages, notamment celui de permettre à des développeurs tiers de créer
des modules répondant à des besoins spécifiques et de les diffuser sous la forme des simples archives ZIP
téléchargeables sur Internet.
Ce document présente la méthodologie à suivre pour développer des nouveaux modules pour Veremap.pro.
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 3/18
2. Le contenu d’un module
2.1 Le stockage du code source
L’application Veremap.pro est constituée de deux interfaces :
- L’interface utilisateur : Veremap.pro
- L’interface administrateur : Veremap.admin
Le code source de ces deux interfaces peut être enrichi de manière à accueillir de nouvelles fonctionnalités.
Veremap.pro
Le répertoire racine de l’interface utilisateur Veremap.pro se nomme par défaut /veremap.pro/. Ce répertoire
contient un sous répertoire nommé /module/.
C’est dans ce sous répertoire de l’application que doit être stocké le code source d’un nouveau module.
Par exemple, le code source d’un module nommé « Consultation des données cadastrales » est stocké dans un
répertoire /cadastre/, ce code source doit être stocké dans le répertoire /veremap.pro/module/cadastre/ de
l’application.
D’une manière générale, hors cas particuliers, le code source du noyau de l’application ne doit pas être
modifié.
Veremap.admin
Le répertoire racine de l’interface administrateur Veremap.admin se nomme par défaut /veremap.admin/. Ce
répertoire contient un sous répertoire nommé /module/.
De la même manière que pour l’interface utilisateur, se répertoire permet de stocker le code source des
nouveaux modules.
Attention, stocker du code source dans ce répertoire n’est utile qu’au cas ou le fonctionnement du module
nécessite la modification de l’interface d’administration (ce point particulier est abordé en 4).
Par exemple, le fonctionnement du module « Gestionnaire de cartes personnalisées » implique que
l’administrateur puisse assurer le nettoyage des cartes temporaires créées dans la base de méta données. Cette
fonctionnalité nécessite une modification de l’interface d’administration et donc le stockage d’un code source
spécifique dans le répertoire /veremap.admin/module/custom_map_manager/.
2.2 Les fichiers aux noms génériques
Une suite de fichiers aux noms génériques peut être utilisée lors de la création du code source d’un nouveau
module.
L’utilisation de ces fichiers n’est pas obligatoire, elle dépend des spécificités liées à l’utilisation de chaque
module. Par exemple, certains modules nécessitent de mettre en place de nouveaux menus et des nouveaux
boutons/outils dans l’interface utilisateur (cadastre) alors que d’autres n’ont besoin d’être accédé que par
l’utilisation d’un bouton unique (cartes personnalisées).
Cependant, il est vivement conseillé de créer ces fichiers dans l’arborescence du module, même s’ils sont
vides.
Certains fichiers génériques peuvent être mis en place pour modifier l’interface d’administration. Ces fichiers
sont présentés dans une sous partie distincte (et ceci sans tenir compte du type de langage de programmation
qui leur est associé).
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 4/18
Les fichiers PHP
Les fichiers PHP aux noms génériques sont toujours stockés dans le répertoire racine du module. Par
exemple : /veremap.pro/module/cadastre/map_toolbar.phtml.
map_toolbar.phtml
Le fichier map_toolbar.phtml permet d’ajouter de nouveaux boutons/outils dans la barre d’outils de
l’interface utilisateur. Il permet également si nécessaire, d’ajouter des attributs cachés dans le formulaire
HTML « mapForm » contenu dans le fichier /veremap.pro/map_toolbar.vhtml.
Le contenu de ce fichier est inclus dans le code du fichier standard du noyau « map_toolbar.phtml » (qui se
trouve dans le répertoire racine de l’application).
Voici la liste des contraintes que doit respecter le code contenu dans ce fichier :
-
-
-
Utilisation de la classe php Tool :
o Cette classe permet de générer des boutons/outils dynamiquement en se basant sur des
valeurs de paramètres tels que la localisation des fichiers images, le nom du code
JavaScript exécuté lors du clic, l’info-bulle associée, etc.
o Le code source de cette classe est contenu dans le fichier /veremap.pro/inc/Tool.class.inc
Préfixer le nom des nouveaux boutons/outils par le nom du module (dans sa version courte, autant
que possible. Par exemple pour le module de « Consultation de données cadastrales » ; un préfixe
« cadastre »).
Stockage des objets de la classe Tool dans une variable php de type tableau nommée $aTools :
chaque objet de la classe Tool est contenu dans une nouvelle occurrence du tableau
Les nouveaux attributs cachés du formulaire HTML mapForm sont sotckés dans une variable php de
type chaîne de caractères nommée $sMapFormHTMLAttribute. Le nom de ces attributs est
préfixé par mf_ .
Exemple : le fichier map_toolbar.phtml du module « Consultation de données cadastrales » qui permet de
créer deux nouveaux outils (cadastre_prc_info et cadastre_fiche_urb) et un nouvel attribut caché
(mf_cadastre_id_par) :
//*** Déclarer ci-dessous les outils du module
$aTools[]=new
Tool("cadastre_prc_info","../../module/".$aModuleInfo[$iKey]["rootDir"]."/images/tools/parc
elle.gif",$TYPE_TOOL,"Fiche descriptive de la parcelle sélectionnée",'','help','','',5);
$aTools[]=new
Tool("cadastre_fiche_urb","../../module/".$aModuleInfo[$iKey]["rootDir"]."/images/tools/fic
he_urb.gif",$TYPE_TOOL,"Fiche d'urbanisme de la parcelle sélectionnée (PDF)",'','help');
//*** Déclarer ci-dessous les attributs de formulaire HTML du module
$sMapFormHTMLAttribute .= "<input type=\"hidden\" name=\"mf_cadastre_id_par\"
value=\"\">\n";
map_form.phtml
Le fichier map_form.phtml permet d’appeler les différents traitements php exécutés lorsque le client utilise
tel ou tel fonctionnalité du module.
En d’autres termes, ce fichier représente la couche de communication entre les classes php permettant de
traiter les requêtes clientes et les fichiers HTML permettant d’assurer la visualisation du résultat de ces
traitements.
Le contenu de ce fichier est inclus dans le code du fichier standard du noyau « map_form.phtml » (qui se
trouve dans le répertoire racine de l’application).
Voici la liste des contraintes que doit respecter le code contenu dans ce fichier :
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 5/18
-
-
Les inclusions des ressources externes (fichiers de paramétrage ou fichiers de classe) se font par le
biais
de
la
commande
require_once("module/".$aModuleInfo[$iKey]["rootDir"]."[chemin_vers_mon_fichier_inclu]
") ou [chemin_vers_mon_fichier_inclu] représente le chemin du fichier source à inclure,
relativement au répertoire racine du module
Les différents cas correspondants à l’utilisation des différentes fonctionnalités du module sont
contenus dans une contidion de type switch
Une condition if englobe le code contenu dans ce fichier (obligatoire), de telle sorte que la structure
du code contenu dans ce fichier corresponde au code suivant :
if($bDefault) {
// Création d’un nouvel objet de la classe associée au module
$oMap = new MaClasse($mesAttributs);
// Gestion des erreur fatales.
// Code "astuce" permettant de traiter les cas d'erreurs fatales non traitées
// par le gestionnaire d'erreur habituel de PHP
$sContent = ob_get_contents();
ob_end_clean();
$sContent = str_replace(ERROR_MSG, "", $sContent);
echo $sContent;
// Fin gestion des erreurs fatales
$bDefault = false;
switch ($_REQUEST["mf_tool"]) {
case "mon_outil" :
// Code à exécuter lorsque mon_outil est utilisé
return;
default :
$bDefault = true;
break;
}
}
Exemple : le fichier map_form.phtml du module « Consultation de données cadastrales » qui permet
d’exécuter le code de la classe php VeremapCadastre lorsque les outils cadastre_prc_info et
cadastre_fiche_urb sont utilisés :
require_once ("module/".$aModuleInfo[$iKey]["rootDir"]."/properties.inc");
require_once ("module/".$aModuleInfo[$iKey]["rootDir"]."/inc/Veremap.Cadastre.class.inc");
if($bDefault) {
$oMap = new VeremapCadastre($sMapFile,$_REQUEST);
// Gestion des erreur fatales.
// Code "astuce" permettant de traiter les cas d'erreurs fatales non traitées
// par le gestionnaire d'erreur habituel de PHP
$sContent = ob_get_contents();
ob_end_clean();
$sContent = str_replace(ERROR_MSG, "", $sContent);
echo $sContent;
// Fin gestion des erreurs fatales
$bDefault = false;
switch ($_REQUEST["mf_tool"]) {
case "cadastre_prc_info" :
$aPrcInfo = $oMap->showCadastrePrcInfo($sMapFile,
$_SESSION["ses_Login"], $_SESSION["ses_Password"], $properties);
include("module/".$aModuleInfo[$iKey]["rootDir"]."/info.vhtml");
exit;
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 6/18
case "cadastre_fiche_urb" :
$sDocFile = $oMap->showCadastreFicheUrb($sMapFile,
$_SESSION["ses_Login"], $_SESSION["ses_Password"], $properties);
include("print_result.vhtml");
exit;
default :
$bDefault = true;
break;
}
}
properties.inc
Le fichier properties.inc permet de stocker les valeurs des variables dont le contenu doit être spécifié par
l’administrateur. Il s’agit du fichier de paramétrage du module.
Voici la liste des contraintes que doit respecter le code contenu dans ce fichier :
-
Utilisation d’une variable php de type tableau nommée $properties["[nom_court_module]"] où
[nom_court_module] représente le nom du module dans sa version courte (« cadastre » par exemple)
Exemple : le fichier properties.inc du module « Consultation de données cadastrales » :
//*** database : nom de la base de données PostgreSQL.
$properties["cadastre"]["database"] = "mabase";
//*** server : nom du serveur PostgreSQL.
$properties["cadastre"]["server"] = "monserveur";
//*** layers : nom de la(les) couche(s) MapServer utilisée(s) lors des requêtes spatiales
//*** Si plusieurs couches MapServer sont utilisées, séparer les noms des couches par un
caractère "|"
$properties["cadastre"]["layers"] = "macouche";
//*** dir : répertoire métier du module Cadastrale.
$properties["cadastre"]["dir"] = $aModuleInfo[$iKey]["rootDir"];
//*** query_by_point_tolerance : tolérance en pixels pour les requêtes par point
$properties["cadastre"]["query_by_point_tolerance"] = 10;
Les fichiers JavaScript
Les fichiers JavaScript aux noms génériques sont toujours stockés dans le sous répertoire /javascript/ du
module. Par exemple : /veremap.pro/module/cadastre/javascript/scripts_cadastre.js.
menu.js
Le fichier menu.js permet de définir :
-
Le nombre de sous menus que contient le menu JavaScript à l’aide de la variable iMenuNbParts.
Par exemple, pour le module « Consultation de données cadastrales » :
//*** Nombre de sous-menu dans le menu du module cadastre
iMenuNbParts = 1;
-
La structure du menu JavaScript à l’aide de la variable MENU_ITEMS_[MODULE] (où
[MODULE] représente la valeur du suffixe du module (Cf. les informations liées au module
stockées dans la base de méta données)). Cette structure reprend la syntaxe spécifique à la mise en
place
d’un
Menu
« Tigra
Menu »,
syntaxe
présentée
à
cette
adresse :
http://www.softcomplex.com/products/tigra_menu/docs/#item_scope . Par exemple, pour le module
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 7/18
« Consultation
de
données
MENU_ITEMS_CADASTRE :
cadastrales »,
voici
le
contenu
de
la
variable
//*** Structure du menu du module cadastre
var MENU_ITEMS_CADASTRE =
[
['LOCALISER', null, null,
['Commune','javascript:map_toolbar.showCadastreForm(\'commune\', 280, 100);'],
['Section','javascript:map_toolbar.showCadastreForm(\'section\', 280, 230);'],
['Lieu-dit','javascript:map_toolbar.showCadastreForm(\'lieu_dit\', 280, 240);'],
['Parcelle','javascript:map_toolbar.showCadastreForm(\'parcelle\', 280, 340);'],
['Parcelle par adresse DGI','javascript:map_toolbar.showCadastreForm(\'adr_DGI\', 310,
320);'],
['Parcelle par adresse
postale','javascript:map_toolbar.showCadastreForm(\'adr_ponctuelle\', 310, 320);'],
['Parcelle par propriétaire','javascript:map_toolbar.showCadastreForm(\'prop\', 310,
500);'],
],
];
-
La position et la taille des éléments constitutifs du menu JavaScript à l’aide de la variable
MENU_POS_[MODULE] (où [MODULE] représente la valeur du suffixe du module (Cf. les
informations liées au module stockées dans la base de méta données)). Une partie de la valeur de la
variable MENU_POS_[MODULE] est générique :
'block_top': iTopPos,
'block_left': iLeftPos,
Par exemple, pour le module « Consultation de données cadastrales », voici le contenu de la variable
MENU_POS_CADASTRE :
var MENU_POS_CADASTRE = [
{
// item sizes
'height': 20,
'width': 77,
'block_top': iTopPos,
'block_left': iLeftPos,
'top': 0,
'left': (document.all) ? 77 : 79,
'hide_delay': 100,
'expd_delay': 100,
'css' : {
'outer': ['m0l0oout_cadastre', 'm0l0oover_cadastre'],
'inner': ['m0l0iout_cadastre', 'm0l0iover_cadastre']
}
},
{
'height': 22,
'width': 190,
'block_top': 22,
'block_left': 0,
'top': 20,
'left': 0,
'css': {
'outer' : ['m0l1oout_cadastre', 'm0l1oover_cadastre'],
'inner' : ['m0l1iout_cadastre', 'm0l1iover_cadastre']
}
},
{
'block_top': 5,
'block_left': 300,
'css': {
'outer': ['m0l2oout_cadastre', 'm0l2oover_cadastre'],
'inner': ['m0l1iout_cadastre', 'm0l2iover_cadastre']
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 8/18
}
}
];
N.B. Le contenu de la variable MENU_POS_[MODULE] fait référence à des définitions de styles
CSS (dans l’exemple « m0l0oout_cadastre » , « m0l0oover_cadastre », etc.). Ces styles sont stockés
dans un fichier nommé menu.css présenté par la suite dans ce document.
scripts_toolbar.js
Le fichier scripts_toolbar.js permet de définir des fonctions JavaScript appelées depuis l’iframe
map_toolbar (voir documentation Veremap.pro) lorsque l’utilisateur exploite les boutons/outils du module.
Dans le cas du clic sur un bouton simple ou du clic sur un élément du menu JavScript, ce fichier peut
permettre de stocker le code d’ouverture d’une nouvelle fenêtre.
Par exemple, lors du l’utilisation du module « Consultation de données cadastrales », un clic sur une des
entrées du menu génère l’ouverture d’une nouvelle fenêtre, ce code est stocké dans le fichier
scripts_toolbar.js du module :
var oCadastreWin;
/**
* Cette fonction permet d'ouvrir la fenêtre formulaire de cadastre.
* \param sUrl URL à charger lors de l'ouverture de la fenêtre.
* \param iWidth Largeur de la fenêtre (en pixels).
* \param iHeight Hauteur de la fenêtre (en pixels).
*/
function openCadastreWindow(sUrl, iWidth, iHeight) {
oCadastreWin =
window.open(sUrl,"cadastre",'screenX=0,left=0,screenY=0,top=0,width='+iWidth+',height='+iHe
ight+',location=no,menubar=no,status=no,scrollbars=no,resizable=no');
oCadastreWin.focus();
}
/**
* Cette fonction permet de définir le type de formulaire cadastral à afficher.
* \param sSessId Identifiant de session PHP.
* \param sType Type de formulaire cadastrale à afficher.
* \param iWidth Largeur de la fenêtre à ouvrir (en pixels).
* \param iHeight Hauteur de la fenêtre à ouvrir (en pixels).
*/
function showCadastreForm(sType, iWidth, iHeight) {
if(bWait == false) {
if(oCadastreWin) oCadastreWin.close();
var sWinUrl = "module/cadastre/cadastre_"+sType+".html";
openCadastreWindow(sWinUrl, iWidth, iHeight);
}
}
D’une manière générale, ce fichier contient donc le code JavaScript du module qui est exécuté depuis le
frameset de l’application Veremap.pro.
beforeSubmit.js
Le fichier beforeSubmit.js permet stocker le code JavaScript du module qui est exécuté avant que le contenu
du formulaire mapForm ne soit envoyé au serveur.
Typiquement, il est utilisé pour exécuter des fonctions JavaScript stockées dans le fichier scripts_toolbar.js.
Commen par exemple, pour le module « Consultation de données cadastrale », la fonction
openCadastreWindow vu plus haut.
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 9/18
Le contenu de ce fichier est inclus dans le corps de la fonction beforeSubmit( ) se trouvant dans l’entête du
fichier map_toolbar.vhtml, lui-même stocké dans le répertoire racine de l’application Veremap.pro.
Le contenu de ce fichier doit donc se limiter à l’énumération d’une suite de cas particulier qui seront inclus
dans la boucle switch du fichier natif. Par exemple, pour le module « Consultation de données cadastrales » :
//*** Module de consultation de données cadastrales
case "cadastre_prc_info" :
document.mapForm.target="cadastre_prc_info";
openCadastrePrcInfoWindow();
break;
case "cadastre_fiche_urb" :
var oTime = new Date();
var sName = "parcel_pdf_"+oTime.getTime();
document.mapForm.target = sName;
openCadastreFicheUrbWindow(sName);
break;
//*** Fin module
Deux cas existent. Ils correspondent à l’utilisation des deux outils qui sont ajoutés à l’interface utilisateur par
ce module. Dans ces deux cas, des fonctions stockées dans scripts_toolbar.js sont appelées (ouverture de
fenêtres).
closeWindows.js
Le fichier closeWindows.js permet de demander la fermeture automatique des fenêtres ouvertes lors de
l’utilisation du module.
En effet, le multi fenêtrage qui peut exister à travers l’utilisation de certains modules implique qu’un fichier
au nom générique permette de stocker du code JavaScript spécifique qui garantit que lorsque l’application
Veremap.pro est fermée, toutes les fenêtres filles de l’application, y compris celles qui sont spécifiques au
module, soient fermées.
Le contenu de ce fichier est inclus dans le corps de la fonction closeWindows( ) se trouvant dans l’entête du
fichier map_toolbar.vhtml, lui-même stocké dans le répertoire racine de l’application Veremap.pro.
Le contenu de ce fichier doit donc se limiter à l’énumération d’une suite de cas particulier qui seront inclus
dans une condition if du fichier natif.
Par exemple, pour le module « Consultation de données cadastrales », le contenu du fichier closeWindows.js
fait référence aux deux objets fenêtre JavaScript contenus dans le fichier scripts_toolbar.js :
//*** Module de consultation de données cadastrales
if(oCadastreWin && !oCadastreWin.closed) oCadastreWin.close();
if(oCadastrePrcInfoWin && !oCadastrePrcInfoWin.closed) oCadastrePrcInfoWin.close();
//*** Fin module
checkWindowConstraint.js
Le fichier checkWindowConstraint.js permet de définir des règles entre les fenêtres filles que peut ouvrir
l’application.
Le contenu de ce fichier est inclus dans le corps de la fonction checkWindowConstraint() se trouvant dans
l’entête du fichier map_toolbar.vhtml, lui-même stocké dans le répertoire racine de l’application
Veremap.pro.
Le contenu de ce fichier doit donc se limiter à l’énumération d’une suite de cas particulier qui seront inclus
dans le fichier natif.
Il est nécessaire d’utiliser ce fichier si par exemple, l’ouverture d’une fenêtre fille du module implique
qu’une fenêtre fille de l’application Veremap.pro soit fermée.
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 10/18
Ce processus est utilisé par le module « Saisie de données », en effet, l’utilisation de ce module, et donc,
l’ouverture de la fenêtre de saisie de données, nécessite de vérifier que la fenêtre de mesures de distances soit
fermée. On retrouve cette l’expression de cette contrainte dans le contenu du fichier
checkWindowConstraint.js de ce module :
//*** Module de création et mise à jour des données
//*** Les fenêtres Outils de mesure et outils de saisie ne peuvent
//*** pas être ouvertes en même temps
if(oFunction == buttonDataCreator)
if(oMeasureToolWin && !oMeasureToolWin.closed) oMeasureToolWin.close();
if(oFunction == buttonSetMeasureToolsVisibility)
if(oDataCreatorWin && !oDataCreatorWin.closed) oDataCreatorWin.close();
//*** Fin module
Les fichiers CSS
Les fichiers CSS aux noms génériques sont toujours stockés dans le sous répertoire /css/ du module. Par
exemple : /veremap.pro/module/cadastre/css/menu.css.
Actuellement, un seul fichier CSS au nom générique est utilisé, il s’agit de menu.css. Ce fichier permet de
mettre en forme le menu spécifique au module. L’intérêt particulier de ce fichier étant de permettre la
différenciation visuelle entre les menus des différents modules et les menus de natifs de l’application
(couleurs, polices, etc.).
Le choix des noms des styles contenus dans ce fichier est libre, mais il est préférable de les suffixer ou de les
préfixer par le nom court du module. Ces styles sont appelés dans le fichier menu.js (voir 3.2).
Il existe un jeu de styles par niveau de menu (menu principal, sous menu, puis éventuellement, menu de sous
menu). Ce jeu de style permet de défnir :
-
Le style utilisé lorsque l’utilisateur survol le menu
Le style utilisé lorsque l’utilisateur ne survol pas le menu (style activé par défaut)
Le style utilisé lorsque l’utilisateur survol le lien HREF
Par exemple, pour le menu principal du module « Consultation de données cadastrales », le fichier menu.css
contient le code suivant :
a.m0l0oout_cadastre:hover {
color: #FFFFFF;
}
a.m0l0oover_cadastre:hover {
color: #FFFFFF;
}
}
.m0l0iout_cadastre {
font-family: Arial, Helvetica, sans-serif;
font-size: 9px;
font-style: normal;
line-height: normal;
font-weight: bold;
text-decoration: none;
padding: 4px;
color: #FFFFFF;
text-align:center
}
.m0l0iover_cadastre {
font-family: Arial, Helvetica, sans-serif;
font-size: 9px;
font-style: normal;
line-height: normal;
font-weight: bold;
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 11/18
text-decoration: none;
padding: 4px;
color: #FFFFFF;
text-align:center
}
.m0l0oout_cadastre {
text-decoration : none;
border:solid;
border-width:0px;
border-color:#FFFFFF;
border-top-width:0px;
border-bottom-width:0px;
border-left-width:0px;
border-right-width:2px;
background: #CA99C8;
}
.m0l0oover_cadastre {
text-decoration : none;
border:solid;
border-width:0px;
border-color:#FFFFFF;
border-top-width:0px;
border-bottom-width:0px;
border-left-width:0px;
border-right-width:2px;
background: #CA99C8;
}
Les fichiers admin
Par fichiers « admin », on fait référence aux fichiers dont les noms sont génériques et qui ont pour vocation
de modifier l’interface d’administration.
D’une manière générale, tous les fichiers du module qui sont stockés après installation dans le répertoire
/veremap.admin/module/[nom_du_module]/ (où [nom_du_module] représente le nom court du module),
doivent être contenu dans le sous répertoire /admin/ du module.
Parmi ces fichiers, certains portent donc des noms génériques :
-
-
menu.js : ce fichier est toujours stocké dans le sous répertoire /admin/javascript/ du module. Il
permet de mettre en place un menu JavaScript spécifique au module dans l’interface
d’administration, sont contenu reprend la même logique que le fichier menu.js contenu dans le sous
répertoire /javascript/ du module (voir 2.2 « Les fichiers JavScript »)
scripts_admin.js : ce fichier est toujours stocké dans le sous répertoire /admin/javascript/ du
module. Il permet d’activer des scripts appelés par le fichier menu.js, il est l’équivalent du fichier
scripts_toolbar.js (voir 2.2 « Les fichiers javaScript ») pour l’interface d’administration.
Typiquement, ce fichier contient les procédures JavaScript d’ouvertures de fenêtres liées à
l’administration du module
2.3 Les fichiers d’installation
Dans Veremap.admin, l’installation des modules se fait à travers l’utilisation d’une interface dédiée. Cette
interface permet d’uploader le code source d’un module puis de lancer son installation.
Quelques consignes sont à respecter pour que ce processus fonctionne :
-
Le code source du module doit être contenu dans une archive ZIP dont le nom correspond à celui du
répertoire racine de cette archive, par exemple, si l’archive contient le code source du module
« toto » version 1.0.0, on stocke ce code dans un répertoire racine « toto-1.0.0 » puis on compresse
ce répertoire dans une archive nommée « toto-1.0.0.zip »
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 12/18
-
Les fichiers d’installation du module doivent être stockés dans un sous répertoire nommé /install/
Ce répertoire doit contenir un fichier php nommé description.inc permettant de détailler les valeurs
à stocker dans la base de méta données pour le module, ces valeurs sont contenus dans une variable
php de type tableau nommé $aModule. Voici la liste de ces valeurs :
o MODULE_NAME : nom du module
o MODULE_VERSION : version du module
o MODULE_AUTHOR : auteur du module
o VEREMAP_VERSION : version de Veremap.pro minimum pour utiliser le module
o MODULE_DESCRIPTION : description du module
o MODULE_ONLINE_DOC : lien HREF vers la documentation en ligne du module
o MODULE_ROOT_DIR : nom du répertoire racine du module
o MODULE_SUFFIX : suffixe appliqué à certaines variables du module (notamment aux
variables JavaScript contenues dans le fichier menu.js, voir 2.2)
o MODULE_INSTALL_DATE : date d’installation du module
Voici un exemple de fichier description.inc :
// Tableau de description du module 'cadastre' - 'Consultation de données cadastrales'
// Version 1.0.0
// Vm Version 1.4.0
$aModule = array (
"MODULE_NAME" => "Consultation de données cadastrales",
"MODULE_VERSION" => "1.0.0",
"MODULE_AUTHOR" => "Veremes",
"VEREMAP_VERSION" => "1.4.0",
"MODULE_DESCRIPTION" => "Module de consultation de données cadastrales (Majic + EDIGEO)
stockées dans une base de données PostGIS. Permet d\'assurer la localisation sur ces
données via des formulaires de localisation, l\'édition de fiches descriptives des
parcelles et de fiches d\'urbanisme au format PDF.",
"MODULE_ONLINE_DOC" => "<a
href=\"http://www.veremes.com/donwload/veremap.pro/module/doc/cadastre.pdf\"
target=\"vm_module_www_doc\">Doc en ligne</a>",
"MODULE_ROOT_DIR" => "cadastre",
"MODULE_SUFFIX" => "CADASTRE",
"MODULE_INSTALL_DATE" => date("Y-m-d H:i:s")
);
-
//
//
//
//
//
//
//
//
Ce répertoire doit contenir un fichier php nommé install.phtml dans lequel se trouve le traitement
d’installation (la copie des fichiers sources) à proprement parlé. Ce traitement peut être librement
développé, une suite de variables php est disponible pour le développeur :
o $sCurrentLog : permet de stocker une chaîne de caractères qui sera ajoutée au log
d’installation. Dans cette chaîne, le mot clé « Echec » peut être utilisé pour signifier qu’une
étape de l’installation est un échec, si ce mot clé est contenu dans le log d’installation,
l’application Veremap.admin considère que l’installation du module est un échec
o $sUnzipModuleDir : chaîne de caractère qui permet de localiser le répertoire dans lequel à
été décompacté le code source du module
o $aProperties : tableau de paramètres spécifiquement utilisée pour l’installation des modules
dont le détaille se trouve dans le fichier /veremap.admin/admin_properties.inc (tableau
$properties["install_module"] )
Voici un exemple de fichier install.phtml :
--Script d'installation des fichiers du module 'cadastre' pour Veremap.pro
--Version 1.0.0
Vm Version 1.4.0 et supérieures
Auteur du module : Veremes - 2006.
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 13/18
// --//
// Gestion du log d'installation
$sCurrentLog = "----\nExécution du script d'installation du module 'Consultation de données
cadastrales' - version 1.0.0 : \n";
// Définition du système d'exploitation en cours d'utilisation
((PHP_OS == "WINNT") || (PHP_OS == "WIN32")) ? $sOS = "Windows" : $sOS = "Linux";
// Test de l'existance du répertoire 'saisie'
// Puis copie des fichiers sources
$sCurrentModuleDir = $aProperties["vm_pro_dir"]."/module/cadastre";
if(!file_exists($sCurrentModuleDir)) {
if(@mkdir($sCurrentModuleDir)) {
switch($sOS) {
case "Windows" :
$sCommand = "xcopy /Y/E ".replaceSlashes($sUnzipModuleDir)."
".replaceSlashes($sCurrentModuleDir);
break;
case "Linux" :
$sCommand = "cp -R ".$sUnzipModuleDir."/*
".$sCurrentModuleDir;
break;
}
$sCurrentLog .= "- Copie des fichiers sources : ";
exec($sCommand, $aCommand, $iResult);
if($iResult == 0) {
$sCurrentLog .= "OK\n";
$sCurrentLog .= "- Veuillez vérifier les valeurs contenues dans le
fichier de paramétrage du module : '".$sCurrentModuleDir."/properties.inc'.\n";
$sCurrentLog .= "- Pour plus d'information sur l'exploitation du
module, veuillez vous reporter à la documentation en ligne.\n";
} else
$sCurrentLog .= "Echec\n";
}
$sCurrentLog .= "----\n\n";
} else
$sCurrentLog .= "Echec, le répertoire destination existe déjà.\n----\n\n";
-
-
Ce répertoire peut contenir un fichier nommé update.phtml dans lequel se trouve le traitement de
mise à jour s’il y a lieu. Ce traitement peut être librement développé, les mêmes variables php sont
disponibles pour le développeur que pour le fichier install.phtml
Noter que les traitements php contenus dans les fichiers install.phtml et update.phtml doivent
permettrent la copie du code source dédié à l’interface utilisateur, et le cas échéant, la copie du code
source dédié à l’interface d’administration
2.4 Arborescence d’un module « type »
Code source du module
Voici l’arborescence du code source de la version du module « type » 1.0.0 :
/type-1.0.0/
map_form.phtml
map_toolbar.phtml
properties.inc
type_form.phtml
type.html
/admin/
/javascript/
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 14/18
menu.js
scripts_admin.js
type_admin.phtml
type_admin.vhtml
/css/
menus.css
/images/
/tools/
module.gif
module_up.gif
module_down.gif
type_image.gif
/javascript/
beforeSubmit.js
checkWindowConstraint.js
closeWindows.js
menu.js
scripts_toolbar.js
scripts_type.js
/inc/
Type.class.inc
/install/
description.inc
install.phtml
update.phtml
Localisation du code source après installation
On considère que le répertoire racine spécifié lors de l’installation (dont la référence se trouve dans la base de
méta donnée) pour ce module est le répertoire « type ».
Interface utilisateur
Dans le répertoire /veremap.pro/module/type/ :
map_form.phtml
map_toolbar.phtml
properties.inc
type_form.phtml
type.html
/css/
menus.css
/images/
/tools/
module.gif
module_up.gif
module_down.gif
type_image.gif
/javascript/
beforeSubmit.js
checkWindowConstraint.js
closeWindows.js
menu.js
scripts_toolbar.js
scripts_type.js
/inc/
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 15/18
Type.class.inc
/install/
description.inc
install.phtml
update.phtml
Interface administrateur
Dans le répertoire /veremap.admin/module/type/ :
/javascript/
menu.js
scripts_admin.js
type_admin.phtml
type_admin.vhtml
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 16/18
3. Le fonctionnement d’un module
3.1 La base de méta données
La base de méta données de l’application Veremap.pro contient une table référençant les modules installés
sur le système ainsi qu’une table dans laquelle sont stockées les associations cartes ↔ modules.
De cette manière, lors du chargement d’une nouvelle carte, l’application est en mesure de charger les
éléments constitutifs de tous les modules associés (menus, boutons/outils).
Lors de l’installation d’un module (via l’interface d’administration Veremap.admin), un log est généré et
permet de vérifier que le processus d’installation s’est bien déroulé.
Si c’est le cas, la référence du module dans le base de méta données aura le statut d’installation « OK ». Seuls
les modules ayant ce statut d’installation pourront être associés aux cartes dans Veremap.admin.
L’exploitation d’un module implique donc que sont installation ait été validée par l’application.
3.2 Les interactions application - module
Lors du chargement de l’interface utilisateur
La phase de chargement de l’interface Veremap.pro est une phase durant laquelle tous les éléments
constitutifs de l’application sont chargés, y compris le code spécifique du ou des modules associés à la carte.
Voici la chronologie des interactions application ↔ module lors de ce chargement (on considère que
/veremap.pro/ représente le répertoire racine de l’application Veremap.pro et que /module/ représente le
répertoire racine du module installé dans le répertoire /veremap.pro/module/) :
1.
/veremap.pro/index.phtml teste l’existence du fichier /module/css/menu.css : si le fichier existe, sa
référence est chargée dans l’entête du fichier /veremap.pro/index.vhtml
2.
/veremap.pro/index.phtml teste l’existence du fichier /module/javascript/menu.js : si le fichier
existe, sa référence est chargée dans l’entête du fichier /veremap.pro/index.vhtml
3.
/veremap.pro/map_toolbar.phtml teste l’existence du fichier /module/map_toolbar.phtml : si le
fichier existe, son contenu est inclus dans /veremap.pro/map_toolbar.phtml
4.
/veremap.pro/map_toolbar.phtml teste l’existence du fichier /module/javascript/scripts_toolbar.js : si
le fichier existe, sa référence est chargée dans l’entête du fichier /veremap.pro/map_toolbar.vhtml
5.
/veremap.pro/map_toolbar.phtml teste l’existence du fichier /module/javascript/beforeSubmit.js : si
le fichier existe, son contenu est inclus dans le corps de la fonction beforeSubmit( ) du fichier
/veremap.pro/map_toolbar.vhtml
6.
/veremap.pro/map_toolbar.phtml teste l’existence du fichier /module/javascript/closeWindows.js : si
le fichier existe, son contenu est inclus dans le corps de la fonction closeWindows( ) du fichier
/veremap.pro/map_toolbar.vhtml
7.
/veremap.pro/map_toolbar.phtml
teste
l’existence
du
fichier
/module/javascript/checkWindowConstraint.js : si le fichier existe, son contenu est inclus dans le
corps de la fonction checkWindowConstraint( ) du fichier /veremap.pro/map_toolbar.vhtml
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 17/18
Lors du chargement de l’interface d’administration
La phase de chargement de l’interface Veremap.admin est une phase durant laquelle tous les éléments
constitutifs de l’application sont chargés, y compris le code spécifique du ou des modules installés et
disposant de fonctionnalités d’administration.
Voici la chronologie des interactions application ↔ module lors de ce chargement (on considère que
/veremap.admin/ représente le répertoire racine de l’application Veremap.admin et que /module/ représente le
répertoire racine du module installé dans le répertoire /veremap.admin/module/) :
1.
2.
/veremap.admin/index.phtml teste l’existence du fichier /module/javascript/menu.js : si le fichier
existe, sa référence est chargée dans l’entête du fichier /veremap.admin/admin.vhtml
/veremap.admin/index.phtml teste l’existence du fichier /module/javascript/scripts_admin.js : si le
fichier existe, sa référence est chargée dans l’entête du fichier /veremap.admin/admin.vhtml
Lors de l’utilisation du module
Les interactions entre les fichiers du module et les fichiers de l’application se font :
-
-
En PHP à l’aide des commandes d’inclusions de fichiers (ces inclusions font le plus souvent appel
aux fichiers contenant des classes php utilisées dans l’application comme Veremap.pro.class.inc ou
MetadataAccess.class.inc)
En JavaScript à l’aide du DOM
Schéma récapitulatif
Veremap.pro – Guide du développeur de module
VEREMES – version 1.0.0
Page : 18/18