bonjour,

j'ouvre ici le sujet pour agrémenter la discussion sur ce document.

maj base de données

• Aujourd'hui j'ai écrit un petit appmgr qui permet à l'instar de DC2, d'installer des modules pour peu que ceux ci possedent les fichiers d'installation requis. J'ai donc adapté ce "schéma" en recuperant les libs clearbrick, gérant l'"UDBS" (Universal DataBase Schema), pour que celles ci puissent faire leur oeuvre sur la base de données sans qu'on est à lever le petit doigt ;)

• Peut-être que pour les mises à jour on pourrait faire comme on le voit ici (à partir de la ligne 36) et on aurait un unique fichier pour les mises à jour / installation recenssant les mises à jour à effectuer.

• De mon coté (avec mon appmgr) j'ai le fichier _install.php comme vu plus haut et un fichier _uninstall.php qui drop la table du module.

maj : les versions

• Dans ce document je découvre le fichier update.xml, je vais donc adapter mon bidule en conséquence puisque je ne m'attachais qu'à trouver un no de version et le comparer à la version actuelle de mon module.

maj du file system

• J'aimerai assez pouvoir gérer le(s) fichier(s) de config en fonction d'un noeud présent dans le fichier update.xml du genre

 <defaultconfig>
  <coordplugins>
    <coord>jacl2</coord>
    <coord>jauth</coord>
  </coordplugins>
 <defaultconfig>

qui indiquerait que mon module a besoin de la présence de 2 plugins dans le fichier de config defaultconfig.ini.php et la presence des fichiers de plugins associés.

• Pour que les mises à jour puissent avoir lieues il faut songer à réclamer un login/passwd à l'utilisateur pour éviter tout installation non voulue (tout comme DC2 ...)

• Pour ce qui est du "bof" sur le draft (en bas de la page) je trouve cela le plus simple justement. On ne cherche pas midi à 14h on remplace tout sauf sa config et son environnement est paré.

Cordialement.

J'ai donc adapté ce "schéma" en recuperant les libs clearbrick, gérant l'"UDBS" (Universal DataBase Schema), pour que celles ci puissent faire leur oeuvre sur la base de données sans qu'on est à lever le petit doigt ;)

si ça ne repose pas sur jDb, ça n'est pas très propre...

Peut-être que pour les mises à jour on pourrait faire comme on le voit ici (à partir de la ligne 36) et on aurait un unique fichier pour les mises à jour / installation recenssant les mises à jour à effectuer.

Je prèfere un update.php pour chaque version car :

• on n'a pas à modifier ce fichier à chaque version.
• on n'est pas obligé de fournir des mises à jour pour toutes les versions dans un même package
• au bout de n version, cet unique fichier update pourrais devenir conséquent, voir inmaintenable.
• au moins le code est plus clair

J'aimerai assez pouvoir gérer le(s) fichier(s) de config en fonction d'un noeud présent dans le fichier update.xml du genre

ce que tu décris là, c'est plutôt prévu pour aller dans le fichier module.xml/plugin.xml, et le xml serait plutôt

  <dependencies>
     <plugin name="" type=""> ...</plugin>
     <module name="">...</module>
  </dependencies>

Va falloir qu'on définisse aussi le format de ces fichiers xml.

Pour que les mises à jour puissent avoir lieues il faut songer à réclamer un login/passwd à l'utilisateur pour éviter tout installation non voulue (tout comme DC2 ...)

Dans un premier temps, faisant les scripts en lignes de commandes, ça sera plus simple. Si c'est fait proprement, tout sera dans des classes, que l'on pourra éventuellement réutiliser dans un module d'admin web.. Le module d'installation par le web, c'est vraiment accessoire pour le moment. Le plus important est de mettre en place le système d'installation/mise à jour

Pour ce qui est du "bof" sur le draft (en bas de la page) je trouve cela le plus simple justement

mouai.. faut voir...

bonjour,

je déterre le sujet et le ticket #31

je me suis remis sur le sujet, mais je ne trouve pas de quoi décompresser une archive dans le framework.

j'ai bien vu la class jZipCreator mais rien pour unzip ...

peut-on ajouter les class zip de clearbrick pour cela ?

ps: j'ai retrouve un backup de appmgr suite à sa suppression malencontreuse que je me suis empressé de mettre sur le projet depot_de_miel;)

A propos de la gestion des dépendances je crois qu'en l'état actuel du format des fichiers module.xml et projet.xml on n'est pas en mesure de distinguer le type du compasant en dependance, exemple :

    <dependencies>
        <jelix minversion="1.1.1" maxversion="1.1.1" />
        <jcommunity minversion="trunk" maxversion="trunk"/>
    </dependencies>

tout le monde se doute que jelix c'est la version du framework et que jcommunity est un module mais ; que'est ce qui les distingue l'un de l'autre ?

si on ne touche pas au schema de definition (où on pourrait ajouter type="framework"/"appli"/"module"/"plugin" etc...) doit on se parcourir tout la structure de l'appli à la recherche de soit un module/appli/plugin ou autre ca risquerait d'être fastidieux non ?

Au travers de appmanager j'ai mis en application les classes et methodes du rep "jelix/installer". Donc rien de transcandant pour appmanager ;)

Faut-il mettre noir sur blanc comment doit s'articuler celles ci ?

Je trouvais les tickets/wiki et les sources elles-même suffisantes pour demarrer l'installeur d'un module, déjà pour constituer le noyeau de ce qui sera l'installeur complet.

J'attends ton Cahier de charges alors ;)