Songbook layout - séparation données/présentation

jmclem commented 10 years ago

Voici ma thèse, sentez vous libre de développer / infirmer / ...

Même si les fichiers .sb mélangent le contenu et la présentation (songs et template sont dans la même structure), je plaide pour une séparation dans notre architecture.

Nous pourrions créer un modèle SongbookLayout qui couvrirait les aspects de la présentation (voir éventuellement la toute première version, qui n'est même pas encore un modèle, ici).

Les instances de SongbookLayout pourraient à la fois être des layouts par défaut (A4, A5, A5R, avec/sans accords, ...) et des personnalisations. Pour la première version, je resterais avec des prédéfinis.

Au moment où le songbook est généré, l'utilisateur choisit une présentation. Les informations issues de cette instance sont mises dans le fichier .sb, et c'est parti.

Ça vous semble cohérent ?

Luthaf commented 10 years ago

Ça peut être cool de faire cette séparation, en effet ! Il faudrait récupérer les options dans les formulaires, et effectuer le stockage dans un JSONField (pour bookoptions).

oliverpool commented 10 years ago

Je pensai justement à cela dernièrement, puisque je conçois des carnets pour un groupe:

une version avec les accords (pour les guitaristes)
une version sans (pour les autres) Le choix de la version devrait être décorrélée du contenu, ce qui correspond exactement à SongbookLayout (en bref :+1: )

Dans le site web, il faudrait demander ces paramètres à la fin, lors de la génération PDF, et non à la création du carnet. De même, je pense qu'il faut différencier le titre (qu'il faudrait appeler "nom" par exemple) du carnet sur le site-web et la première de couverture.

Luthaf commented 10 years ago

De même, je pense qu'il faut différencier le titre (qu'il faudrait appeler "nom" par exemple) du carnet sur le site-web et la première de couverture.

C'est à dire ? Permettre d'utiliser un titre personnalisé, en pré-remplissant le champ avec la valeur de songbook.title ?

oliverpool commented 10 years ago

par exemple

Un nom de carnet serait "Carnets des scouts de Bures", alors que ma première de couverture serait plus "Camp scout 2014", sous-titre "Bures".

Luthaf commented 10 years ago

Ok. Ça doit être possible sans problème avec la séparation Songbook/Layout =)

(une preuve de plus de l'efficacité de la séparation fond/forme !)

jmclem commented 10 years ago

Si je comprends bien, on aurait dans Songbookles arguments

name : visible sur le web
title, subtitle : utilisés pour la génération

C'est bien ça ?

oliverpool commented 10 years ago

c'est effectivement ce à quoi je pensais (ça peut probablement être amélioré)

Luthaf commented 10 years ago

Moi je voyais plus title et subtitle dans la partie Layout que dans la partie Songbook.

jmclem commented 10 years ago

Moi je voyais plus title et subtitle dans la partie Layout que dans la partie Songbook.

Est-ce pour pouvoir le spécifier au moment de la génération du PDF ? Pour moi, ça reste tout de même du contenu. Si je devais dicter/déclamer un songbook, title et subtitle en feraient partie... donc contenu.

Luthaf commented 10 years ago

Je ne sais pas trop. A quoi sert le title du songbook alors ? Est-il utilisé à la compilation ? Sinon j'ai l'impression que ça fait duplication : on a un title pour le web et un title pour le PDF.

jmclem commented 10 years ago

On peut commencer avec Songbook.title et Songbook.subtitle; si le besoin s'en fait sentir, on pourra toujours rajouter un champ spécifique pour l'affichage sur le site. En attendant, on utilise Songbook.title. Ça vous va?

oliverpool commented 10 years ago

ok

Luthaf commented 10 years ago

Farpait !

Luthaf commented 10 years ago

La question des templates/layout est actuellement en discussion ici : patacrep/songbook-core#18. En gros, l'on s'oriente vers une possibilité d'avoir plusieurs templates, et d'en extraire dynamiquement la liste des options. Ce la pourrait être utilise lors de la création d'un Layout, qui n’aurait du coup plus besoin d’être un modèle.

Il suffirai de proposer un choix entre les templates, avec un aperçu du rendu, puis d'extraire la liste des options, de la convertir en formulaire, de récupérer le formulaire et de renvoyer le tout au moteur. Quel est votre avis sur la question ?

Luthaf commented 10 years ago

Je propose aussi que Layoutsoit un vrai modèle, donc conservé en BDD, ce afin de pouvoir partager et réutiliser les mises en page d'un carnet à l'autre. Du coup, une première ébauche du modèle serait :

Layout:
user = OneToOneField(User)
template = OneToOne(Template)
values = JSONField()

Template:
name/path = CharField()
Options = JSONField ?

Le problème principal avec cette vision est comment générer les formulaires/la liste des options connaissant les variables disponibles dans les templates. On peut le faire soit automatiquement en lisant les fichiers pour y récupérer les variables, mais cela expose un grand nombre de variables "avancées" à l'utilisateur. Sinon, on peut aussi générer "à la main" la liste des champs de formulaire correspondant à un template. Mais c'est de la belle méta-programmation =)

Luthaf commented 10 years ago

Commencé dans le commit 1454fea0731a237235ccb7dbcbab96f243dbbbf0

Luthaf commented 10 years ago

Le problème principal avec cette vision est comment générer les formulaires/la liste des options connaissant les variables disponibles dans les templates.

Ce genre de solution me convient : http://stackoverflow.com/a/3713490 On va chercher les variables, leurs valeurs et leur descriptions lors d'un import en base de donnée, et on s'en sert pour générer des formulaires de création de mise en page. Nouvelle version du modèle :

Templates
     path = CharField
     name = CharField
     description = CharField
     variables = ManyToMany(TemplateVariables)

TemplateVariables
    name = CharField
    description = CharField/JsonField. Contient un dictionnaire des traductions des descriptions
    value_type = ??
    value = ??

Layout
    name = CharField
    description = CharField
    template = ForeignKey(Template)
    options = ManyToMany(TemplateVariables, through OptionsInTemplates)

OptionsInTemplates
    layout = FK(Layout)
    variable = FK(TemplateVariables)
    value = CharField ???

La principale difficulté revient alors a être capable de stocker intelligemment les différents types de variables, et de vérifier les entrées utilisateurs. Une autre solution serait l'utilisation d'une GFK vers des modèles des types de variables. Pour l'instant, il existe comme types

Color: 6 caractères hexadécimaux
List
String
Bool/Flag

Des avis sur cette modélisation ?

oliverpool commented 10 years ago

il peut aussi y avoir des nombres entiers/flottants, non ? (la taille de la police, marges, taille de la page...)

Luthaf commented 10 years ago

Oui, en effet.

jmclem commented 10 years ago

Je ne me suis pas intensément penché sur la question, donc c'est peut-être hors sujet, mais j'ai vu ceci qui concerne les champs dynamiques en bdd : http://stackoverflow.com/questions/7933596/django-dynamic-model-fields/7934577#7934577

oliverpool commented 10 years ago

J'ai du mal à tout suivre, mais je crois avoir saisi l'idée. Du coup j'ai une idée (peut-être à côté de la plaque): je copie l'approche de Laravel. Les seules modifs sur ton modèle:

TemplateVariables
    name = CharField
    description = CharField/JsonField. Contient un dictionnaire des traductions des descriptions
    rules = CharField //comme laravel, cf ci-dessous

OptionsInTemplates
    layout = FK(Layout)
    variable = FK(TemplateVariables)
    value = CharField

Pour les rules, il s'agit d'une liste des règles de validation en série (le | sert à mettre en série). Par exemple:

in:foo,bar,... la valeur doit être foo ou bar ou ...
integer|min:5|max:10 la valeur doit être un entier entre 5 et 10
required|min:5 chaine d'au moins 5 caractères ...

Luthaf commented 10 years ago

Je ne me suis pas intensément penché sur la question, donc c'est peut-être hors sujet, mais j'ai vu ceci qui concerne les champs dynamiques en bdd : http://stackoverflow.com/questions/7933596/django-dynamic-model-fields/7934577#7934577

Globalement, on a (principalement) deux choix pour stoker les donnes :

Sous forme de paires attribut/valeur. Soit avec une base SQl, soit avec une base NoSQL (le second est je pense un peu overkill dans notre cas)
Sous forme de dictionnaires sérialisé, dans un JSONField ou autre.

Le choix de modifier les tables en temps réel ne me convient pas vraiment dans ce cas.

Et on a aussi deux choix pour récupérer les valeurs des variables

En les important, puis en mettant les champs en BDD
Avec une lecture dynamique des variables lors de la création de la mise en page.

Dans les deux cas, il va falloir faire attention que si le template change, les valeurs en BDD risque de ne plus être a jour. Toutefois, ceci étant vrai aussi pour tous les fichiers .sb des utilisateurs de songbook-core ; je pense que l'interface restera stable de ce point de vue.

Enfin pour la validation des donnes, on a aussi plusieurs choix. Dans tous les cas, il est plus naturel de le faire dans un formulaire.

On peut avoir les règles de validation par variable dans la BDD
On peut avoir des règles de validation par type dans la BDD
On peut avoir des règles de validation dynamique déduites des templates par variables
On peut avoir des règles de validation par type dans le code du formulaire.

Après réflexion, je pense qu'il serait peut-être plus simple d'avoir des paires attribut/valeur, une lecture dynamique des données, et des règles de validation déduites des templates. Mais je croit qu'il va falloir essayer avant de decider vraiment.

jmclem commented 10 years ago

Je ne connais pas bien songbook-core, donc je pose la question : serait-il possible de proposer une première version des layouts dans songbook web qui grosso modo permettrait de choisir

la taille et l'orientation de la page
titre et sous-titre
la présence des accords
- la présence ou non des grilles d'accord (pour chanque chant / en index)
- la langue des accords
la présence des images

Le tout sans tentative de faire des formulaires / modèles dynamiques (ça pourra venir ensuite).

Luthaf commented 10 years ago

la taille et l'orientation de la page

Pas encore, mais c'est simple a ajouter avec un nouveau template. Je pensais ajouter un template songbook-web de toute manière, avec plus d'options. Entre autres des choix de

Taille et orientation du papier
Couleur, corps et style des polices pour les refrain, accords, couplets.

titre et sous-titre

Ce sont les clefs title et subtitle des fichiers .sb et de leurs représentations JSON.

la présence des accords

Clef booktype : chorded pour les accords, lyric sans les accords

la présence ou non des grilles d'accord (pour chanque chant / en index)

Clef diagram dans bookoptions pour afficher les positions d'accords. Pour la liste en index, il faut changer de template, mais cela peut être modifie.

la langue des accords

Par defaut, si le carnet est en francais, (clef lang valant french), les accords sont affiches en notation solfege. On peut forcer une notation avec notenamesout, qui peut valoir alphascale ou solfedge.

la présence des images

Clef pictures dans bookoptions

Le tout sans tentative de faire des formulaires / modèles dynamiques (ça pourra venir ensuite).

Dans tous les cas, on est bien oblige de faire un formulaire pour récupérer les entrées utilisateur.

Je termine la détection de la tonalité des chansons (c'est moins important, mais plus marrant) et je m'attelle a ce problème, sauf si tu veux t'y mettre.

EDIT : il faudrait aussi permettre un upload d'images par les utilisateurs pour choisir les images de couverture, puis plus tard pour insérer des images dans le carnet (voir #63).

jmclem commented 10 years ago

J'essaye de commencer quelque chose; si les doigts te chatouillent, n'hésite pas à me faire signe !

jmclem commented 10 years ago

Dans tous les cas, on est bien oblige de faire un formulaire pour récupérer les entrées utilisateur.

tout à fait d'accord, mais je partirais pour du statique dans un premier temps

Luthaf commented 10 years ago

Pourquoi pas. J'ai juste peur que la transition soit difficile a migrer. Mais cela serait plus rapide en effet.

Je ferais un template pour songbook-web, avec choix des polices et des couleurs ce week-end. Je te laisse le reste =)

jmclem commented 10 years ago

J'ai fait quelques premiers pas, mais bute sur un problème que ma maigre connaissance de sb-core m'empêche de diagnostiquer correctement. J'ai pushé sur mon clone (jmclem/songbook-web). Attention, c'est du WIP, ce n'est pas encore fini ! (entre autres, un Layout est créé à chaque génération, ça changera).

Vue succinte des modifs :

Modèles : ajout de champs "title", "subtitle" et "author" dans Task pour pouvoir customiser au moment de la génération du PDF (ici)
Tâches : le paramètre principal est maintenant la Task (qui lie aussi vers Layout), et non plus le Songbook (ici)
Vues : ajout d'une vue /songbooks/<id>/setup-rendering qui affiche le formulaire et lance la génération (ici)

Le principe fonctionne, mais le PDF qui est généré est vide de chants (les pages de garde et cie sont bien là). Toutefois, si j'écris le contenu dans un fichier (ici), ça donne:

{'author': u'Jean-Marie Cl\xe9ment',
 'authwords': {'sep': ['and', 'et']},
 'bookoptions': [u'lilypond'],
 'booktype': u'chorded',
 'content': ['les_cowboys_fringants/entre_deux_taxis.sg',
             'les_cowboys_fringants/histoire_de_peche.sg',
             'les_cowboys_fringants/la_manifestation.sg',
             'les_cowboys_fringants/etoiles_filantes.sg',
             'les_cowboys_fringants/l_horloge.sg'],
 'datadir': '/home/jean-marie/dev/songbook/patacrep/songbook-web/../songbook-data/',
 'lang': u'french',
 'subtitle': u'blibli',
 'template': u'patacrep.tex',
 'title': u'Un',
 'version': '0.1'}

Toutefois, si je corrige un peu le format (les u, l'accent, les guillements), j'arrive à le compiler correctement en ligne de commande.

@Luthaf, as-tu une idée de ce qui ne fonctionne pas ?

Luthaf commented 10 years ago

@Luthaf, as-tu une idée de ce qui ne fonctionne pas ?

Oui, une des dernières modifications de songbook-core n'était plus compatible songbook-web. J'ai corrigé ici : https://github.com/patacrep/songbook-core/commit/afffdb19b168362cc0b392cb095a4d23498c57af

Sinon, j'aime bien tes modifications. J'aurais mis title, author et subtitle dans Layout et pas dans Task, mais cela se discute.

Luthaf commented 10 years ago

Template ajouté pour régler les polices : https://github.com/patacrep/songbook-data/blob/next/templates/fonts.tex.

L'utilisation est dans le commit : https://github.com/patacrep/songbook-data/commit/a1eca37f809bbcf6e49c5ef1cdf930ad580cddac, il faut bien entendu utiliser ce template dans le fichier.sb/le dictionnaire renvoyé par Layout.

jmclem commented 10 years ago

Ok, merci @Luthaf, ça marche maintenant. J'ai fait un push sur ma repo (https://github.com/jmclem/songbook-web).

Voilà comment je l'ai conçu :

l'utilisateur demande la génération d'un fichier PDF par les liens déjà présents
il est redirigé vers un écran où
- il peut revoir les PDFs générés et avec quelles options et télécharger directement
- ou demander la génération avec un nouveau jeu de paramètres. Dans ce cas, il est redirigé sur l'ancien render

Cela fait toutefois deux endroits où sensiblement la même information est affichée : le nouveau setup_rendering : screenshot from 2014-05-24 18 48 44

et songbook_private_list :

screenshot from 2014-05-24 18 52 09

Je réfléchis encore à l'organisation des écrans pour éviter les redondances; si vous avez déjà des commentaires, je suis preneur !

Luthaf commented 10 years ago

Beau boulot !

Pour l'organisation des liens, ça risque de changer pour améliorer le design. La discussion a été commencée ici : https://github.com/patacrep/songbook-web/issues/61

jmclem commented 10 years ago

merci :)

Je regarderai les liens

Est-il déjà possible de configurer une taille de page et orientation ?

Luthaf commented 10 years ago

Est-il déjà possible de configurer une taille de page et orientation ?

Pas encore, mais c'est simple à mettre en place. Par contre, j'ai peur que cela ne se limite pas à changer la mise en page, et qu'il faille aussi modifier les options de mise en forme des chants. Ce sera plus simple si on se contente de proposer quelques options :

A4 A5 A6, et peut-être un format carré
portrait ou paysage

jmclem commented 10 years ago

Ça me paraît tout à fait acceptable de limiter à ce que tu proposes. Comment peut-on mettre ça en place ?

Luthaf commented 10 years ago

Il faut changer les options du package geometry. Je peut faire un autre template, ou bien l'ajouter au précédent.

D'un point de vue de la syntaxe, quelque chose comme "papersize" : "A4" et "orientation" : "landscape/portrait" devrait suffire.

jmclem commented 10 years ago

Pour l'organisation des liens, ça risque de changer pour améliorer le design. La discussion a été commencée ici : #61

Zut, j'avais oublié cette discussion. Du coup, mon travail est un peu en porte à faux. Je me rabats sur #61 pour continuer la discussion.

Il faut changer les options du package geometry. Je peut faire un autre template, ou bien l'ajouter au précédent.

Je veux bien que tu le fasses, ce sera sûrement plus efficace ;)

D'un point de vue de la syntaxe, quelque chose comme "papersize" : "A4" et "orientation" : "landscape/portrait" devrait suffire.

:+1:

jmclem commented 10 years ago

Je voudrais revenir de manière plus générale sur la génération de carnets.

Il y a aujourd'hui

le carnet au sens de l'interface (ensemble ordonné de chants et de sections, avec un titre et une description) (Songbook)
le carnet au sens PDF (généré depuis le précédent, qui peut présenter un titre, une description et un auteur différents des précédents) (GeneratorTask)

Un carnet-interface peut conduire à plusieurs carnets PDFs, avec des paramètres différents.

Les paramètres sont le format d'impression d'une part. D'autre part, il y a aujourd'hui aussi les champs Auteur, Titre et Sous-titre. Je pense que c'est utile pour le champ 'Auteur' (depuis mon compte 'Bernard Bianca' je peux générer un PDF qui aura comme auteur 'Le nom de ma troupe'). L'est-ce pour les chants 'titre' et 'sous-titre' ? À mon avis pas aujourd'hui. On pourrait aussi ramener le champ Auteur dans le Carnet (Songbook)

Je proposerais donc bien de modifier ce que nous avions commencé et que j'ai prolongé dans mes dernières modifs vers qqc comme:

ajouter un champ displayed_author dans Songbook
utiliser Songbook.titleet Songbook.description comme titre et sous-titre
le formulaire de génération de PDF ne contiendrait alors que le layout.

Qu'en dites vous ?

Luthaf commented 10 years ago

Titre et sous-titres peuvent sauter et être pris dans Songbook à mon avis. Pour le chant displayed_author, je suis pour en avoir un, après s'il doit aller dans Songbook ou Layout, je ne sais pas trop.

jmclem commented 10 years ago

Je ne le mettrais pas dans layout car ce n'est pas de la présentation. (il aurait aussi sa place dans une lecture du texte, ou une impression en ascii) Songbook ou GeneratorTask ? La question est s'il est susceptible de changer d'une impression à l'autre ? Je partirais en disant que non, ça me parait plus simple, donc je le mettrais dans Songbook.

Luthaf commented 10 years ago

Ça me va.

Luthaf commented 10 years ago

Il faut changer les options du package geometry. Je peut faire un autre template, ou bien l'ajouter au précédent. Je veux bien que tu le fasses, ce sera sûrement plus efficace ;)

C'est fait : https://github.com/patacrep/songbook-data/commit/ed421698ab23ac6cc8724a463374ce3d70f6e303. J'ai tout remis dans le template data.tex. Vu que les options par défaut sont les même qu'avant, cela ne change pas grand chose.

Par contre, la mise en page de la page de titre et des pages d'accords ont des comportements étranges, il faut que je modifie tout ça.

jmclem commented 10 years ago

j'ai essayé, sans effet. À quel niveau dois-je mettre les paramètres "orientation" et "papersize" ? Pour l'instant, je les ai mis comme ça :

    def get_as_json(self):

        d = {"subtitle": self.subtitle,
             "title": self.title,
             "orientation": self.layout.orientation,
             "papersize": self.layout.papersize,

Luthaf commented 10 years ago

Tu as bien les dernières versions de core et data ? Le template est bien data.tex ?

sinon, peut-tu poster le fichier .tex produit ?

jmclem commented 10 years ago

ok, merci, conforté par le fait que c'était au bon endroit, j'ai tout stoppé, relancé, et ça marche ! cool.

Je verrai plus tard pour changer les marges (elles sont très large en haut et en bas de chaque page sur du A5 paysage).

Luthaf commented 10 years ago

Oui, il reste encore un peu d'esthétique à faire : chants sur une seule colonne en A5 portrait, placement des accords au début du carnet, marges, ...

J'ai commencé mais pas fini.

oliverpool commented 10 years ago

La séparation Songbook/GeneratorTask me convient ! (j'ai surtout hâte de la version ASCII que va nous sortir @jmclem ;-)

jmclem commented 10 years ago

j'ai surtout hâte de la version ASCII que va nous sortir @jmclem ;-)

:D

jmclem commented 10 years ago

Oui, il reste encore un peu d'esthétique à faire : chants sur une seule colonne en A5 portrait, placement des accords au début du carnet, marges, ... J'ai commencé mais pas fini.

OK, je touche pas et j'attends. Peut-être peut-on essayer aussi 3 colonnes en A4 portrait.

Luthaf commented 10 years ago

Peut-être peut-on essayer aussi 3 colonnes en A4 portrait.

Pour l'instant, le nombre de colonne est écrit en dur dans chaque fichier .sg. Il va falloir modifier tous les fichiers de songbook-data pour permettre de changer le nombre de colonnes je croit.

patacrep / patanet

Songbook layout - séparation données/présentation #36