Song edition - Githubissues

oliverpool commented 9 years ago

Poursuite de #50.

Puisqu'on part sur un format de fichier chordpro, on esquive normalement la plupart des problèmes de sécurité.

Au niveau de l'interface, je verrai bien une zone comme github (avec des onglets - mais probablement situés en bas):

Edition: quelques input (titre, artiste) et une liste de textarea avec select (refrain, couplet, pont)
Aperçu (qui fait un rendu en HTML)
Texte Brut (un textarea contenant tout le chant) - pratique pour les copier/coller notamment.
Modifications (pour montrer les différences avec la version précédente, dans le cas d'une modification)

Au niveau technique, je pense utiliser le texte brut comme référence et synchroniser les autres onglets via javascript (du coup python reçoit juste le contenu du textarea).

Concernant l'édition concurrent par deux personnes, j'imagine un système de "compare-and-swap". Lors de l'édition, on embarque le hash (md5) du fichier dans la page (input hidden). Lors de la soumission, le fichier est vérouillé (avec https://pypi.python.org/pypi/lockfile par exemple), le hash est calculé:

si le hash correspond, on remplace le contenu du fichier par le contenu du textearea, et on dévérouille
si le hash ne correspond pas, on l'indique à l'utilisateur avec une page de diff qui liste les lignes où il y a des conflits: on demande alors à l'utilisateur quelles sont les lignes qu'il a modifié.

Luthaf commented 9 years ago

si le hash ne correspond pas, on l'indique à l'utilisateur avec une page de diff qui liste les lignes où il y a des conflits: on demande alors à l'utilisateur quelles sont les lignes qu'il a modifié.

Ça sent assez fort l'usine à gaz ça. On doit pouvoir trouver quelque chose de plus simple à implémenter qui soit encore utilisable. Pour une V1, pourquoi ne pas bloquer simplement toute édition par un autre utilisateur pendant N min ?

Sinon le reste me semble pas trop mal =)

oliverpool commented 9 years ago

On peut effectivement faire un lock pendant un certain temps, mais si la personne soumet le formulaire après, comme le gère-t-on ?

Luthaf commented 9 years ago

Soit le fichier est locké par quelqu'un d'autre, et on invite à recommencer dans N min, soit il ne l'est pas et on peut en effet comparer un hash pour décider d'accepter ou de refuser les modifs.

Soundy25 commented 9 years ago

On peut effectivement faire un lock pendant un certain temps

Je suis perso pas tellement pour les blocages dans une appli... l'opérateur devrait être autonome et ne jamais faire face à une "opération infaisable". Si on ne peut l'éviter, je prone généralement une information précise du genre : "Le fichier est actuellement en cours d'édition par $user, (Accès impossible)" En plus l'objet devra être disabled pour ne pas proposer l'édition d'un objet non éditable. (... peu importe la raison)

oliverpool commented 9 years ago

Les locks à N min offrent aussi un vecteur d'attaque pour éviter toutes les éditions de chants. Et si le temps est trop court, le verrou risque d'expirer avant que l'utilisateur ait fini...

Luthaf commented 9 years ago

C'est vrai. Mais je n'ai pas mieux qui n'expose pas l'ensemble de la machinerie git à l'utilisateur. Je vais y réfléchir un peu =)

oliverpool commented 9 years ago

Le hash que j'ai évoqué n'est pas nécessairement en lien avec git: juste un "bête" md5 du fichier quelque soit sont état dans git.

oliverpool commented 9 years ago

Dans un premier temps, si le hash a changé entre-temps, on peut simplement demander à l'utilisateur de répéter ses changements (pas de diff ou autre - pour éviter de l'effrayer)

oliverpool commented 9 years ago

@Luthaf : je souhaite faire quelques tests d'interface. Que me conseilles-tu pour "pseudo-récupérer" les données ? (contenu du chant, titre de l'album, langue...) J'ai pensé à écrire des fonctions dans songs.py du style get_song_text, get_song_album pour éviter de trop surcharger le modèle.

Dans un premier temps, ces fonctions renverront un Lorem Ipsum, puis une fois le format ChordPro finalisé, elles retourneront les bonnes valeurs.

Luthaf commented 9 years ago

J'ai pensé à écrire des fonctions dans songs.py du style get_song_text, get_song_album pour éviter de trop surcharger le modèle.

Ces fonctions peuvent être des méthodes/propriétés du modèle Song, ça ne me pose pas de problème. Si les fichiers deviennent énormes, on peut faire comme pour les vues et ajouter un module models.

oliverpool commented 9 years ago

Même si patacrep/patadata#19 n'est pas encore complètement résolue, j'ai commencé un éditeur live pour ChordPro: https://github.com/oliverpool/chordpro-editor.

Il est pour l'instant extrêmement simple: il rajoute seulement un arrière plan aux différents types de paragraphes qu'il connait.

Il est difficile de faire mieux qu'un arrière plan sans devoir faire un nombre considérable d'ajustements (en cas de sélection, de suppression du markup...).

En revanche, il est tout à fait possible de rajouter des boutons pour transformer un paragraphe en refrain, verse ou autre.

Au niveau backend, cela ne change rien: le textarea (contenant le code songpro "pur") sera envoyé directement.

Pour des raisons de simplicité, je pense qu'il faut séparer les paroles et le reste (titre, album, définition des accords & co.)

Luthaf commented 9 years ago

:100:

patacrep / patanet

Song edition #132