Introduction

Le but de ce document est de décrire le nouveau besoin concernant le nouvelle gestion des plugins dans XINX.

Tickets concernés

Status: closed (5 matches)

Ticket Summary Component Milestone
#316 Règle de développement à partir de la 140 XINX (Projects) 0.9.0.0
#333 Boite de dialog nouveau projet Generix Plugin Generix Plugin 1.0.0.0
#334 Nouvelle gestion de RCS XINX (Library) 0.9.0.0
#291 Rendre XINX plus modulaire XINX (Plugins) 0.9.0.0
#311 Mise à jours de la boite de dialogue de personnalisation XINX (Plugins) 0.9.0.0

Points à traiter

  • Avoir deux notions (le but est de ne plus dépendre pour QFrame pour AbstractEditor, et de laisser les plugins présenter l'éditeur selon leur volonté) : [Ok]
    • Les classes éditeurs de XINX présentant les composants (éditeur, ...) et les interactions entre eux.
    • Les classes afficheurs. Générant la présentation final de l'éditeur à l'écran. C'est classe afficheur sont traité dans une méthode de la classe éditeur.
      • Le point est géré différemment. La classe AbstractEditor hérite toujours d'un QFrame. Par contre une méthode virtual void initLayout(); permet d'initialiser le layout de l'objet et donc de le modifier. Le Layout de la classe AbstractEditor ne fait rien par contre celui de la classe TextFileEditor initialise un layout avec uniquement l'éditeur. Cette méthode étant appelé après la création de l'éditeur, il est possible d'initialiser le layout par héritage.
  • Mettre au point la dépendance inter-plugin (attention au cycle). [Reporté]
  • Interface de résolution des dépendances (pour les imports), fait au travers de ContentViewParser::locationOf, mais aussi pour ajout de fonction au parsing XSL (Peut-être au travers du plugin WEB). Peut-être déplacer locationOf au niveau d'une interface adéquate. [OK]
  • L'interface de résolution des dépendances doit être activable/désactivable suivant la version du projet ou d'autre paramètre. [OK]
    • C'est au plugin de determiner s'il prend en charge la résolution ou non. Tout les plugins sont testé jusqu'à résolution du nom. Cela permet d'utiliser un resolver pour les js et un autre pour les xsl.
  • Agrandir XinxPluginLoader : au lieu d'une classe gérant tout, faire une classe gérant des parties. [Reporté]
  • Une ou plusieurs interfaces pour pouvoir gérer le projet comme actuellement. Par exemple, sauvegarde, ... voir aussi contenue du ticket #316. [OK]
  • Sauvegarde des fichiers (points rassembler dans une boite de dialogue) : [OK]
    • Copie du fichier standard en fichier spécifique avec préfixe (avec conservation du standard)
    • Ajout au referenciel.
    • Avoir la liste des BV utilisé.
  • Onglet projet, pouvoir afficher (information pouvant se trouver à différents endroits suivant la version) : [OK]
    • La langue
    • Le navigateur
    • Le nom du fichier pour le flux de présentation
    • La version du module

  • Vue contenue [OK]
    • Recherche des fichiers d'include (utilisable également pour le parsing)
  • Le parsing de feuille de style passe par xsltproc et par la librairie (pouvoir ajouter des fonctions et des variables, ...) [KO]

Idée

  • Sélection de la version du projet dans les propriétés projets (et/ou autodétection) et activation/désactivation des modules en fonction. [OK]