laurentj a dit :
Youhou \o/ !

Juste un truc à propos de la barre de menu : comme ça sera un site à part, il aura sa propre barre de menu. Pas la peine de reprendre les items pointant sur jelix.org.

Ok nickel

Et sur jelix.org, je vais réfléchir où on placera les sites "annexes" sur la home et les autres pages (si vous avez des idées...). Et du coup bouger le "contribute" sur le site principal.

les sites annexes sont actuellement : developer.jelix.org, planet.jelix.org, download.jelix.org. Et ensuite je compte bouger les manuels et la référence API vers docs.jelix.org et api.jelix.org (séparer les manuels du reste allégera le wiki actuel, pour qu'il soit moins lent, enfin j'espère).

je trouve pas le manuel lent personnellement .

Et enfin il y aura booster.jelix.org

\o/

Sur le site principal ne restera que tout ce qui est communication / marketing (news, forums, pages de présentation du fmk, liste des releases/download etc...).

Qu'en pensez vous ?

ca me parait clair.

Après peut-être que ça aura un impact sur le référencement ?

Donc ok ca roule pour la barre ; je vais faire un truc avec la barre unie bleue claire et BOOSTER en blanc dedans :) ; je push sur bitbucket apres je laisserai aux designers le soin de s'exprimer :)

une question quand meme, je conserve l'affichage du template "status" de jcommunity en haut à droite ? histoire de trouver toujours cela au meme endroit invariablement du site "annexe".

@FlorienLB : voilà les sources sont en place sur BitBucket. On peut exploiter le bugtraker de BitBucket pour suivre où on en est dans la roadmap http://developer.jelix.org/wiki/fr/drafts/booster et s'assigner les tickets pour se repartir le taffe ;)

bonne nuit :)

je trouve pas le manuel lent personnellement .

Si, il m'arrive souvent que quand je vais sur le wiki après une longue période, la première page soit horriblement lente. Je crois que c'est parce que dokuwiki doit faire quelque chose avec l'index ou l'historique, quand personne n'est pas venu un certain temps sur le wiki.

Donc j'essaierai de voir deux solutions : la première, de faire plusieurs install de dokuwiki (à la limite, un wiki par manuel), ou la deuxième, virer tout l'historique (et le conserver quelque part).

Après peut-être que ça aura un impact sur le référencement ?

Pour le référencement, je vais bien sûr mettre en place des redirections. Pour les utilisateurs déjà, ce sera plus agréable, avec tout les liens qui pointent vers les pages du manuel sur le forum par ex...

@laurentj: j'en pense que ca me va.

Voici où on en est avec FlorianLB :

Page d'accueil + moteur de recherche

Page d'affichage d'un élément et ses versions

encore des details à règler ;)

Sympa, ça avance bien on dirait :-)

Cependant je trouve le design un peu fouilli. J'éspère aussi que le code HTML est clair, avec des id clair, et des classes significatives, pas avec des classes de partout aux noms bizarres comme dans hfnu ;-)

Ensuite, y a un truc que j'avais pas trop indiqué dans le cahier des charges : la compatibilité avec jelix. Je pense que c'est important. Il faut pouvoir indiquer pour une version donnée, avec quelles versions de jelix c'est compatible. J'arrive pas à me décider si ça reste un tag, ou si on a un champs spécifique indiquant la liste des versions jelix compatibles (il faut pouvoir en indiquer plusieurs). Le problème du tag, c'est qu'il faut le renseigner correctement, avec la bonne casse, et au finale on risque de se retrouver avec des "JELIX 1.2", "Jelix 1.2", "Jelix1.2", "jelix 1.2.x" etc... je serais donc plutôt favorable à un champs spécifique. Il faudrait aussi pouvoir indiquer un masque (1.2.*), un intervalle (1.2.2 -> 1.2.*)... Faut donc peut être plusieurs champs en base (crée et rempli de manière à faciliter la recherche) et un ensemble de contrôles de formulaire qui puisse permettre d'indiquer tout ça facilement lors de l'enregistrement. à propos de recherche, le plus simple pour l'utilisateur : un seul champs où il indique la version de jelix qu'il utilise. au moteur de recherche ensuite de se débrouiller.

Autre chose : le "booster qu'est ce que c'est" + welcome : à n'afficher que sur la home de l'appli.

j'ai mis tout ca ds des tickets bitbucket

Laurent, on se pose des questions sur le dernier besoin de compatibilité des versions jelix :)

Comment verriez vous la page d'accueil ?

https://bitbucket.org/foxmask/booster/issue/1/home-page#comment-533812

Je recopie un echange de mail qui aurait dû arriver ici :)

laurentj:

foxmask à dit :
Bonjour,
je me retrouve un peu perdu dans le process d'installation d'une application.

Quand on teste une réinstallation, à part supprimer le cache + le fichier var/config/install.ini.php et vider sa base de données, doit-on retirer toute reference moduleAAA.access=X dans les fichiers de config des points d'entrée et dans le defaultconfig.ini.php ?

Si tu supprimes les .access dans la config, ton module ne va pas être installé ou mis à jour. Donc il ne faut pas les retirer. c'est de la configuration !

De ce que j'ai testé, si je ne mets pas de dépendance sur le module jtags dans le fichier booster/module.xml mais que j'ai toujours jtags.access=2 dans var/config/index/config.ini.php alors lors du php installer.php l'application cherche à installer jtags ...et hélas pour moi, pas sur le bon profil :/

qu'il cherche à installer jtags, c'est normal. je ne comprend pas ce que tu cherches à faire là. L'installer sans l'installer ?

Pour indiquer le profile, dans la config, section modules, jtags.dbprofile=xxx

Et pourquoi tu veux installer jtags sur un profile différent de booster ?

Autre test, j'ai voulu installer jtags à la main mais on ne peut pas spécifier de "profile" :/

php cmd.php installmodule jtags -profile xxx

jelix répond xxx n'est pas un module :/

Oui effectivement. ce paramètre n'existe pas. tu aurais affiché l'aide de la commande, tu l'aurais vu :)

Peux tu me dire ce qu'il faut mettre dans le config.ini.php + default.ini.php et module.xml en terme de dépendances ?? Et si je fais un "php installer.php" ou si j'installe les modules un à un ?

les dépendances, ce sont dans les module.xml. pas autre part. dans la config, tu met les modules que tu veux installer pour ton appli.