Project

General

Profile

Conception

La documentation

La documentation est maintenant rassemblée dans ce wiki. La documentation LibreOffice n'est plus maintenue. Elle s'articule autour des sections:
  • La documentation d'installation dans ce wiki Installation
  • La documentation utilisateur
  • La documentation des développeurs

Architecture

Comme la plupart des logiciels sur internet GVV est architecturé en Modèles / Vues / Contrôleurs. C'est à dire que pour chaque module on va trouver:

Vues
  • Des vues qui sont responsable de gérer la disposition des informations à l'écran. On utilisera ou pas un mécanisme de template, mais l'idée est la. La vue doit fournir une structure avec des trous, le contrôleur fournit l'information pour remplir les trous.

Contrôleurs
  • Des contrôleurs qui sont responsables de la logique de l'application.

  • C'est eux qui vont être activés par les différents choix de menus ou les boutons
  • C'est eux qui vont aller chercher l'information en base de données pour la fournir aux vues
  • C'est eux qui choisissent les vues à afficher en fonction du contexte.

Modèles
  • Des modèles qui interagissent avec la base de données.

  • Ils extraient l'information
  • Ils la modifient

Afin de rester le plus simple possible, les modèles, vues et contrôleurs s'appuient sur des librairies de fonctions auxquelles ils délèguent certaines actions.

La plupart des interactions qu'on va avoir avec le modèle de données sont de type (CRUD), c'est-à dire Create, Read, Update and Delete. On va donc créer, consulter mettre à jour et détruire des informations.

Toujours dans un but de simplification on notera deux choses dans GVV.

La plupart des contrôleurs héritent du contrôleur GVV_Controller qui est capable de gérer un CRUD simple. Dans le cas de fonctionnalités simple comme
la gestion des avions ou des planeurs, la plupart des actions sont réalisés par le parent. Il n'y a que pour les fonctionnalités complexe qu'on est obligé de redéfinir les traitements dans les contrôleurs enfants. Cela permet de minimiser le code.

Dans la même logique, la plupart des modèles héritent de Common_Model.

Il n'y a que les vues qui ne sont pas des objets qui n'héritent pas les unes des autres. On risque quand même de mettre en place un mécanisme équivalent pour prendre en place les spécificités des différents clubs.

Structure du programme

Il est découpé en petits modules chacun responsable d'une seule chose. De cette façon est plus facile d'avoir chacun notre propre version de chacun de ces modules. Bien sur il faut que le maximum des modules reste communs, sinon cela ne sert à rien de travailler en équipe.

  1. On sépare la partie look du code HTML avec une utilisation systématique des feuilles de styles. Il y a des feuilles séparées pour le style et le positionnement. Comme cela chacun peut afficher où il veut ses éléments avec son propre look.
  1. Architecture MVC (Modèles, vues, contrôleurs). Séparation très net des modules qui s'occupent de la base de données (les modèles), de l'affichage (les vues) et de la logique de l'application (les contrôleurs). Architecture la plus courantes sur les sites WEB professionnels.

L'utilisation des métadonnées

La programmation orientée modèle ou la programmation basée sur les métadonnées utilise une description du modèle de données pour savoir comment les traiter. Dans notre cas on utilise le schéma de la base de données.

Plutôt que de coder l'affichage pour chaque vue et chaque formulaire le programme exploite les informations de description des données disponibles dans la base. Il en extrait la liste des tables, des champs ainsi que les types et longueur des champs. Ces informations auto-descriptives sont complétées dans le programme lui-même (GVVMetadata.php). Un entier par exemple peut être utilisé comme un entier pour coder une altitude de remorquage, comme une valeur booléenne ou comme l'encodage d'une liste de valeur (type de décollage array(1 => 'Treuil', 2 => 'Autonome', 3 => 'Remorqué', 4 => 'Extérieur');). Donc au type de donnée extrait de la base, on ajoute éventuellement un sous-type qui spécifie son utilisation dans le programme.

De cette façon pour afficher une table ou une vue, il y a deux choses à faire:
  1. enregistrer le résultat du select:
  2. demander l'affichage de la table dans la vue

enregistrer le résultat du select

    $select = $this->select_columns('macmodele, macimmat, macconstruc, macplaces, macrem, maprive, actif', $nb, $debut);
    $this->gvvmetadata->store_table("vue_avions", $select);

demander l'affichage de la table dans la vue

$attrs = array(
    'controller' => $controller,
    'actions' => array ('edit', 'delete'),
    'fields' => array('macmodele', 'macconstruc', 'macimmat', 'macplaces', 'macrem', 'maprive', 'actif'),
    'count' => $count,
    'first' => $premier,
    'mode' => ($has_modification_rights) ? "rw" : "ro");

echo $this->gvvmetadata->table("vue_avions", $attrs);

De même pour afficher un champ de formulaire, il suffit de référencer la table et le champ pour que le programme calcul automatiquement le type de saisie désiré.

echo ($this->gvvmetadata->form('ecritures', array(
'date_op' => $date_op,
    'annee_exercise' => $annee_exercise,
    'compte1' => $compte1,
    'compte2' => $compte2,
    'montant' => $montant,
    'description' => $description,
    'num_cheque' => $num_cheque,
    'categorie' => $categorie,
    'gel' => $gel
)));

Cette approche a plusieurs avantages:
  1. Moins de code a écrire, le code est écrit pour chaque type de donnée (date, boolean, montant, etc.), pas pour chaque données.
  1. plus rapide à écrire
  2. moins de maintenance
  1. Garantie de l'homogénéité de l'affichage et du comportement
  2. Homogénéité entre l'affichage et les exports CSV et PDF.

Cela impose d'utiliser systématiquement result_array() qui retourne le résultat sous forme d'un tableau associatif.

Les commentaires associés aux champs sont utilisés dans les formulaires comme descripteur de champs. Cela permet un minimum d'auto documentation du modèle de données.

Validation des formulaires

On utilise le mécanisme de CodeIgniter et la plus grande partie des règles est déduite des types et sous-types. Il n'y a que dans les cas particuliers qu'on ajoute des règles de validation supplémentaires.

Les données doivent être présentées aux formulaires dans plusieurs cas:
  • Initialisation avec les valeurs par défaut avant création
  • Chargement des valeurs d'un enregistrement pour édition
  • Rechargement d'un formulaire dont les règles de validation ont échouées

Le format de stockage et le format d'affichage ne sont pas forcément identique. Il doit donc y avoir une étape de transformation entre le format base et le format d'affichage, ainsi qu'une transformation entre le format de saisie et la base.

La Galaxie Google

GVV fournit tous les services spécialisés pour la gestion d'un club (gestion des vols, facturation, etc). Pour les services généraux; gestion de documents, agendas, visualisation de traces, etc. Il est plus judicieux de s'appuyer sur les développements Google.

Interface avec Google