Editeur de texte "google doc like" : pagination

Bonjour,

Je travaille actuellement sur une application web qui doit contenir un éditeur de texte. Par éditeur de texte, je ne parle pas d'un ckeditor mais plutôt d'un google doc like ou d'un word like (en bien plus simple). Je souhaite utiliser un script d'édition en live comme aloha editor mais j'ai un problème sur la pagination du contenu.

Je n'arrive pas à comprendre quel est le principe derrière le système de pagination des éditeurs tels que google doc ou zoho. Je m'explique : je parle ici du comportement qui nous parait tt à fait normal sous word et les autres.

• j'ai une première page
• je remplis ma page et celle-ci remplie, en ajoutant du contenu, une autre page est ajoutée
• ainsi de suite et inversement si je supprime du contenu

Jusque là pas compliqué. Ce qui l'est plus c'est si je descend ou rajoute du contenu dans la première page, tt le contenu au dessous du contenu modifié descend et peut donc changer de page ou en créer une nouvelle. Inversement si on supprime du contenu.

De plus, si on change la taille de caractère du contenu (une ligne par exemple), une partie du contenu peut par exemple changer de page.

Qq aurait il une idée de comment sont gérés ces cas ? ou plutôt comment est géré le contenu global ou de chaque page ?

J'ai inspecté Google Doc avec le debugger chrome et chaque page est un div différent. Mais je ne vois pas comment calculer la taille du contenu de chaque page, en fonction des lignes laissées vides, de la taille des polices, des éventuels tableaus, images, ...

Je me doute que ce n'est pas une question simple mais sait on jamais si qq a une idée. Je demande pas de me le coder mais plus un principe sur lequel démarrer car je ne sais pas par où prendre le problème.

Merci d'avance pour le retour. N'hésitez pas à m'envoyer un message si besoin.

Bonne journée
Bastien

perso, ce que je ferai (pas la moindre idée si c'est la bonne solution ou non) c'est que je créerai un seul et unique document(page dans un seul div) de rendu.

que je clonerai et afficherait en décalé (verticalement) sur chaque "page", en masquant la partie qui dépasse au dessus et en dessous. (overflow:hidden)

et lors de l'édition d'une "page", je n'éditerai en réalité que le document global que je reclonerai en permanence(enfin lors des onkeypress) dans les autres pages.

le clonage permanent de DOM est p-ê un peu lourd, mais en général tu n'as (j'imagine) que maximum 2 pages de visibles à la fois sur l'écran, donc si l'une d'elle possède le "document" original, il ne faut plus faire qu'un seul clone pour l'autre page. (acceptable je pense). et un refresh global lors d'un premier scroll après édition (ou autres changement de mise en page).

bonne chance. ;-)


edit: au pire, pour ne pas cloner tu grisses les autres page lors de l'édition de l'une pour ne pas avoir à rafraichir autre chose. enfin, je ne sais pas comment fonctionne exactement la méthode "non-récursive" du clone de noeuds du dom, p-e que les objets dedans sont uniques et font référence à un seul contenu, dans ce cas, ce serait parfait pour toi. (à voir).

Merci pour la réponse.

Je t'avoue que je pensais pas à qq chose comme ça. Ca me parait très lourd à gérer si j'ai par exemple des documents de plusieurs dizaines de pages avec des images par exemple.

J'ai trouvé des sources de kix, la solution développée par google. J'ai cru comprendre en lisant des forums qu'il y avait peu de chance que la base de l'éditeur Kix passe en open source.

Je vais regarder s'il y a une API pour me brancher sur cet éditeur directement et l'intégrer à mon appli. Ce qui me dérange beaucoup dans ce cas, c'est la dépendance complète à un produit google...

J'imagine que mon problème n'est pas simple. Google a ajouté la pagination à google doc seulement en mars 2011. Mais, je vois mal mon éditeur sans cette fonctionnalité.

Citation:

---

Envoyé par bastien31000

Google a ajouté la pagination à google doc seulement en mars 2011. .

---

8O

j'avoue ne jamais avoir utilisé google doc, mais ils faisaient comment avant alors ? (ou alors, je n'ai pas compris ce que tu voulais par pagination).

pour l'open source, s'il s'agit d'une page en javascript, le code est toujours accessible avec un clique-droit "afficher le code source". sauf si une partie de la page est faite en flash(par exemple) mais ce n'est pas dans les habitudes de google.

enfin, un clone n'est pas si lourd, tu peux éventuellement ajouter une condition de temps minimum (par exemple 3 secondes) si ton utilisateur tape super vite. avec la méthode native cloneNode et un pc pas trop ancien, ça ne devrait pas être trop lourd, même avec des images qui seront forcément en cache et donc ne devront pas être rechargées.

bonne chance.:ccool:

J'ai un peu oublié l'ancienne version, mais il semblerait qu'avant il n'y avait que le compact mode, c'est à dire un seul bloc qui contenait tt le document et les changements de pages étaient identifiés par des lignes pointillées horizontales.

Il n'y avait pas de vue paginée du document telle qu'on peut l'avoir sous word.

Pour ce qui est du nouveau google doc, kix, j'ai trouvé les explications du fonctionnement ici : http://googledocs.blogspot.com/2010/...ogle-docs.html

Et en gros, le browser ne fait plus rien, c'est l'appli complètement javascript qui dessine tt (juqu'au curseur), qui gère tout en terme de layout de placement, qui calcule donc les tailles de chaque lettre, entrée, espace, tableau, ...

Evidemment, dans ce cas, c'est pas le plus dur de savoir quand changer de page... par contre, je me vois pas me lancer là dedans.

concernant le javascript, il y a 2 scripts accessibles mais ils sont compactés (je sais pas si c'est le bon mot), donc illisible.

Je vais essayer de trouver une solution en restant avec du contentEditable.

j'avais du temps à perdre alors je viens de passer 30 minutes à te faire un exemple qui te plaira, je l'espère.

http://www.hommk.net/cpm/pagination.htm

clique-droit afficher la source, tu verras, elle n'est vraiment pas longue et donc facile à comprendre (même si mes nom de variables ne sont pas très parlant).

;)


edit:
http://www.hommk.net/cpm/pagination2.htm
voici une seconde version qui n'a plus besoin de div pour cacher le contenu qui dépasse car il ne dépasse plus. et gère le problème du scroll grace à l'événement "onscroll". il y a également qqes commentaires pour utiliser ce onscroll pour détecter la sortie du curseur de texte (barre clignotante) de la zone visible (vers le bas) et permettre un saut du focus sur la page suivante. il faudrait aussi une version pour la remontée du curseur mais tu vas galérer car il n'existe pas de moyen de detecter la position(coordonnées) de ce "cursor barre clignotant" et le seul moyen que j'ai trouvé pour palier à ça est de detecter quand des scrolls se font.

peut-être que ma solution n'est alors pas la bonne et que tu devrais créer des document différents (au lieu d'en cloner un seul).

je ferai donc un onscroll pour le document qui est édité, dans ce cas(du scroll), faire une boucle de vidage qui va enlever les dernières lettres une à une et les placer dans la "page" suivante tant que le "scrollTop" est différent de 0.

réciproquement pour la suppression de caractère, j'utilisera le onkeyup (ou onkeypress) et si la longueur du texte diminue, j'injecte les caractères de la page suivante en placant le "cursor barre clignotant" en fin de selection (après avoir pris soin de sauver sa position) jusqu'au onscroll. (ou jusqu'a que la page suivante soit vide). (le onscroll devra replacer le dernier caractère en trop sur la bonne page.)

si le onkeyup ne change pas la taille de ma selection mais qu'il sagit de la touche "effacer à gauche"(au dessus de enter) et que mon "curseur barre clignotant" était en début de texte, je délete le dernier caractère de la page précédente et j'execute la procédure de vidage ci-dessus.


bref, ça à l'air hyper compliqué, mais en réalité ça l'est. (mais ça devrait fonctionner car javascript offre tout ce dont tu as besoin pour implémenter ma description ci-dessus.)

bonne chance. :mrgreen: :mrgreen: :mrgreen:

wow !!! je regarde le code et je me dis "mais bien sûr" ! ca a l'air tellement évident quand c'est bien fait et qu'on l'a devant les yeux !

franchement, chapeau ! :) et merci ! :)
vu comme ça, je comprends bcp mieux ce que tu me disais avant.

Je vais regarder tout ça, comprendre tt ce que me dis dans le dernier message et me lancer là dedans. En effet, javascript semble offrir tt ce qu'il faut pour s'en sortir, mais ca sera compliqué. Et j'ai l'impression qu'on a pas le même niveau de programmation. Mais bon, je peux que progresser dans tous les cas !

sinon, une question en passant (le forum est peut etre pas le bon endroit) : tu es freelance ? on sait jamais, si j'ai des devs ultérieurs...

merci encore pour ton temps, tes explications et ton code :)

Bastien

Citation:

---

Envoyé par bastien31000

sinon, une question en passant (le forum est peut etre pas le bon endroit) : tu es freelance ? on sait jamais, si j'ai des devs ultérieurs...

---

je ne suis pas vraiment freelance, je n'ai pas encore eu l'occasion de travailler en tant que codeur. (j'ai arreté mes études il y a un an et demi suite à des problèmes de santé et puis financiers et puis je n'ai pas voulu reprendre cette année.) je bosse sur des projets personnels (pas tous liés à l'informatique) dont un en javascript qui commence à prendre de l'ampleur (qqes milliers de visiteurs uniques par jour) mais ça ne paie pas mon pain (150€ de pubs adsense / mois) donc un projet freelance serait le bienvenu.

Citation:

---

Envoyé par bastien31000

Je vais regarder tout ça, comprendre tt ce que me dis dans le dernier message et me lancer là dedans. En effet, javascript semble offrir tt ce qu'il faut pour s'en sortir, mais ca sera compliqué. Et j'ai l'impression qu'on a pas le même niveau de programmation. Mais bon, je peux que progresser dans tous les cas !

---

courage et bonne chance. :ccool: