Gestion de documents - Page 1

Je pense me lancer dans un projet permettant de créer et d'éditer un document (d'un type perso) pas trop lourd (pour de très gros documents, 1Mo).

* J'ai déjà un éditeur en client lourd fonctionnel (Python + PySide) dont j'aimerais me débarrasser (pour deux raisons : j'aurais besoin d'un serveur web reprenant une partie des fonctionnalités, et j'aimerais éviter Qt).
* Dans tous les cas de figure, j'ai besoin de conserver une bibliothèque Python sur ce type de documents.

Or donc©, je souhaite passer le plus simplement possible d'un éditeur en client lourd à un éditeur en client léger.
J'ai identifié trois possibilités :

* tout recoder en JS, mais 1) ça me demande de faire beaucoup de JS, et 2) ça fait de la duplication de code,
* utiliser Brython (Python over JavaScript), au prix d'une bonne pénalité en termes de perfs,
* réussir à conserver le document en mémoire côté serveur (alors qu'il y a potentiellement plusieurs processus et que ça contredit un peu le principe de HTTP — accessoirement, il n'y aura jamais trop d'utilisateurs simultanément).

La meilleure solution me semble être la troisième, mais je ne sais pas trop comment faire. Peut-être via des websockets ? Serais-je passé à côté d'une autre solution ?

flanker (./1) :
* tout recoder en JS, mais 1) ça me demande de faire beaucoup de JS, et 2) ça fait de la duplication de code, * utiliser Brython (Python over JavaScript), au prix d'une bonne pénalité en termes de perfs,

Dans ces cas, ton "client léger" est en fait un client lourd en JavaScript.

* réussir à conserver le document en mémoire côté serveur (alors qu'il y a potentiellement plusieurs processus et que ça contredit un peu le principe de HTTP — accessoirement, il n'y aura jamais trop d'utilisateurs simultanément).

Ça correspond plus à l'idée du web.

Ce que tu cherches, n'est-ce pas une simple gestion des sessions? Il y a des solutions toutes prêtes pour ça (et aussi les autres problèmes que tu risques de rencontrer). En Python, tu as par exemple le framework Flask, utilisé pour les applications web de Fedora. Il est libre sous une licence BSD (donc sans copyleft). Je ne peux pas fournir d'expérience personnelle, mais l'équipe web de Fedora ne jure plus que par ça (ils utilisaient Turbogears à une époque, mais il paraît que ce soit plus ou moins mort).

Kevin Kofler (./2) :
Dans ces cas, ton "client léger" est en fait un client lourd en JavaScript.

Si tu veux

Kevin Kofler (./2) :
Ce que tu cherches, n'est-ce pas une simple gestion des sessions? Il y a des solutions toutes prêtes pour ça (et aussi les autres problèmes que tu risques de rencontrer). En Python, tu as par exemple le framework Flask, utilisé pour les applications web de Fedora. Il est libre sous une licence BSD (donc sans copyleft). Je ne peux pas fournir d'expérience personnelle, mais l'équipe web de Fedora ne jure plus que par ça (ils utilisaient Turbogears à une époque, mais il paraît que ce soit plus ou moins mort).

Mais les sessions passent par des sérialisations, et c'est justement ce que je veux éviter.

et framapad et autres trucs du genre, ca irait pas?

C'est un éditeur de texte, j'ai besoin d'un éditeur graphique sur mesure (sans compter que la partie édition n'est qu'une des fonctions de la partie web, même si c'est la plus complexe) ^^

Au final, j'ai pris une approche qui n'est pas très propre, mais qui me permet d'être rapidement efficace :

* je pars du principe que cette partie-là du serveur sera dans un seul processus
* le document est chargé en mémoire côté serveur
* quand un client fait une action (par exemple déplacer un élément), à la fin de l'action le client envoie l'action au serveur, qui modifie le document en conséquence, et qui envoie une action en retour (déplacer réellement l'élément à l'affichage).

Sur le papier, ça fait un peu doublon (le client déplace un élément, puis le serveur lui dit de se déplacer au même endroit), mais ça permet (quand je passerai aux websockets) d'avoir deux clients qui éditent le même document, et de valider (ou non) chaque modification.
Au final, toute l'intelligence reste côté serveur, ce qui m'arrange pas mal pour limiter le code côté JS.

oui, et puis ça empêche le maphack, et les... euh non, rien