Closed Luthaf closed 10 years ago
jmclem
commented
10 years ago À mon sens, la "gestion des chants" de la feuille de route concerne l'édition via l'app web. Je trouve judicieux d'abord faire la gestion de recueil avec une base de chants fixe, non modifiable, et la génération PDF parce que c'est la fonctionnalité principale de l'application, et l'aspect qui comporte le plus d'inconnues.
Luthaf
commented
10 years ago Je suis d’accord pour la base de chants fixe dans un premier temps.
Par contre pour gérer l'ajout/modification de songbooks, il faut d'après moi déjà importer la base de chant actuelle dans la BDD web (juste les méta-informations), pour pouvoir générer les *.sb depuis l'interface web. C'est ce que je voulais dire.
La feuille de route deviendrait alors :
jmclem
commented
10 years ago Hmmm, chez moi, sous Linux, j'avais utilisé la branche principale, qui me semble être celle utilisée actuellemen. Ca avait bien fonctionné, à part l'install manuelle nécessaire de quelques packages TeX.
Luthaf
commented
10 years ago La branche master fonctionne en effet, mais la partie moteur du songbook est actuellement en évolution (cf http://www.patacrep.com/forum/viewtopic.php?id=69).
L'idée est de supprimer tout appel à make, et de faire des appels plus simples : songbook.py -s my_songbook.sb. Ce type d'appel est beaucoup plus simple à utiliser (il ne faut pas créer de Makefile pour chaque .sb) depuis un serveur web. Visiblement, la branche master actuelle ne réécrit pas l'intégralité du Makefile, mais simplement des fichiers .d listant les dépendances pour chaque songbook.
Bref, en tout cas je préfère attendre la nouvelle version, quitte à travailler un peu dessus, plutôt que d'utiliser l'ancienne (qui de plus ne permet pas de changer l'emplacement de la bibliothèque de chants)
jmclem
commented
10 years ago Hmmm... "attendre" l'avancée d'un tel logiciel me semble risqué. (ce n'est aucunement une critique, mais un constat que "ça se fait quand ça se fait", ce qui est normal pour des logiciels basés sur la bonne volonté et le temps disponible des collaborateurs).
J'opterais ici d'utiliser d'abord ce qui existe, même si ce n'est pas parfait, pour ensuite soit bénéficier d'une amélioration en provenance de patacrep, ou de faire l'amélioration de notre côté et en la proposant à patacrep.
Le fait que la dernière contrib sur le post que tu cites et sur la branche "next" du client date d'il y a 10 mois me renforcent dans cette idée.
oliverpool
commented
10 years ago La dernière proposition de feuille de route me convient : je pense qu'il serait judicieux d'écrire un script qui se charge de lire l'arboresence de *.sg actuelle et d'insérer les infos dans la bdd (ainsi il suffirat de faire git pull, puis un appel au script pour mettre à jour un dépot github)
Luthaf
commented
10 years ago Oui, j'approuve l'idée du script ! Ça ne doit pas être trop compliqué à faire.
Concernant la compilation avec la branche 'next', elle fonctionne finalement chez moi : il s'agissait d'un problème d'encodage lors de la génération des index, qui semble résolu en réglant l'encodage par défaut de python, plus un petit patch. Je reste favorable à l'utilisation de cette branche (il ne manque que la compilation lilypond) car elle est plus pratique, et permet l'output dans un répertoire quelconque avec peu de modifications.
De plus il sera aussi plus facile d'implémenter des personnalisations (je pense surtout aux \songsection) avec cette version. Comme elle est finalement fonctionnelle a minima, je pense que l'on peut se permettre de s'en servir =) S'il faut aussi modifier cette part là du code, ça prendra un peu plus de temps mais je pense qu'un site fonctionnel d'ici l'été est un objectif atteignable.
jmclem
commented
10 years ago Ok, si ça fonctionne, c'est bien ! Heu, c'est quoi, "a minima" ? ça fait quoi bien et quoi moins bien ?
jmclem
commented
10 years ago avec tous ces débuts de recherche, je ne sais pas exactement ce que vous avez commencé et ce à quoi je pourrais m'attaquer. Je propose de créer des issues pour les fonctionnalités que l'on peut s'assigner, pour savoir qui travaille sur quoi.
Ça vous va ?
Luthaf
commented
10 years ago a minima c'est que ça compile les carnets de chants, mais sans les partitions lilypond pour l'instant, et sans options de personnalisation.
Sinon, pour les issues, ça me va =)
jmclem
commented
10 years ago J'aimerais bien pouvoir m'assigner une issue pour pouvoir signaler que je m'en occupe, mais je pense qu'il y a une réduction de droits par github. Luthaf, as-tu la possibilité de nous monter d'un cran dans la hiérarchie (je ne la connais pas) ? De même, je n'ai pas la possibilité de labeliser les issues.
Luthaf
commented
10 years ago Je vous ai mis collaborateurs, est-ce que c'est bon ?
oliverpool
commented
10 years ago C'est bon ! (je viens de faire un push direct)
[je crois que je ne vous ai pas encore dis que mes compétences en python/django étaient assez limitées... Mon expérience sur le framework laravel écrit en PHP me permet quand même de comprendre rapidement le code - à défaut d'en écrire rapidement ;- ]
jmclem
commented
10 years ago Tiens, Laravel, ça m'aurait bien dit aussi, j'ai fait du PHP, jamais de python... Mais on va pas te faire ce coup là, Luthaf ;) ?
Luthaf
commented
10 years ago En soi, on peut discuter, ouvrez une autre issue si vous pensez que Laravel serait plus adapté, je ne suis pas fermé =). Après je préfère python et Django pour quelques raisons :
Route::get('log/{nom?}', array('as' => 'log', function($nom = null)
{
if($nom) return $nom;
else return 'Vous devez vous connecter !';
}));
Route::get('login/{nom?}', function($nom = null)
{
return Redirect::route('log', array($nom));
});Et pour la version Django, on sépare le routage des vues et des modèles. Quelque chose d'équivalent au code ci-dessus serait :
============== Dans le urls.py
urlpartern = pattern('',
url(r'^log/(?P<nom>;+)$','show_nom',name='nom'),
url(r'^log/(?P<nom>;+)$','show_nom_login'),
)
============== et dans views.pys
def show_nom(request,nom):
return HttpResponse(nom)
def show_nom_login(request,nom)
return redirect('nom',nom)Voilà. J'ai quelques raisons objectives, et un paquet de subjectives. De plus, je ne connais pas du tout Laravel (j'ai regardé les 7 premiers chapitres d'un tuto (http://laravel.sl-creation.org/category/laravel_4/page/17/)). Et aussi, il y a un tuto Django sur le site du Zéro et pas de tuto Laravel =p
oliverpool
commented
10 years ago Il a fermé l'issue pour éviter qu'on en parle ;-)
Perso ca ne me dérange pas de découvrir autre chose!
jmclem
commented
10 years ago Pareil, c'était un ;) , ça me plaît de découvrir python/django. Ça peut rester fermé !
La feuille de route du wiki est actuellement :
Pour moi, la gestion des chants doit être faite avant la gestion des recueils : il est plus facile de gérer un recueil si on a une liste de chants par ailleurs. D'autre part, cela laisse le temps pour terminer de séparer le moteur des données pour la compilation en PDF.
De plus, pour la partie 'rôles', je pense que des groupes d'utilisateurs sont suffisants : un groupe modérateur, un groupe admin. Tout utilisateur non connecté est considéré comme un visiteur par Django, les deux premières catégories sont immédiates.