Besoin d'idées pour finaliser une "JMappedBufferedTextArea"

Après de nombreuses réponses de ma part sur ce forum, voici une question. J'aurais besoin d'idée(s) de personnes ayant déjà bossé sur les composants texte avec swing.

Tout d'abord, voici mon idée de départ : créer un composant texte ( type JTextArea dans un premier temps ) qui serait "mappé" sur un fichier texte ( peu importe l'encodage, tous sont gérés mes classes décrites plus bas). C'est à dire que seule la partie visible du composant serait chargée en mémoire dans le composant. Les données visibles seraient extraites d'une part du fichier d'origine et des modifications successives - qui elles seraient bufferisée en mémoire.
A cela deux très gros avantages pour moi :
- Limiter l'occupation mémoire de la JVM dans le cas de gros fichier ( seules les parties visibles le seraient ).
- Limiter les I/O en stockant les modifs en mémoire ( toujours dans le cas de gros fichiers ). En effet, pas besoin de recopier l'intégralité d'un fichier de 2 GO à chaque insertion de caractère.

Bon j'abrège sur la technique :
J'ai créé deux classe TextFile et BinaryFile qui remplissent parfaitement le rôle décrit plus haut. Pour cela elles utilises les méthodes suivantes :
void insert(long offset,Datas datas); // insertion on l'aura compris
void delete(long offset,long length); // '' ''
void replace(long offset,long length,Datas datas); // ''
mais surtout :
Datas getFinal(long offset,long length);
qui me permet de récupérer à n'importe quel instant une partie du fichier final, c'est à dire une fois toutes les modifications effectuées ( ce de manière logique ).

Donc voilà ma question à présent : quel serait pour vous le meilleur moyen d'intégrer ma classe TextFile dans un composant graphique de type texte ?
- J'avais pensé dans un premier temps utiliser DocumentFilter pour mettre à jour le contenu du composant ( je l'ai déjà utilisé, c'est pour ça que j'ai pensé à lui ), mais j'ai un doute sur la propreté d'une telle méthode.
- Ne serait-il pas plus judicieux de faire comme pour les composants MVC ( JTable, JTree etc. ), gérer le contenu au niveau du modèle ? Dans ce cas, quoi faire : étendre Document, PlainDocument, ou autre ?

Toute proposition sera la bienvenue ;)

Faisant cela pour des besoins personnels, je peux fournir le code si des personnes sont intéressées, je suis l'auteur de la totalité. Une fois la question swing résolue, je proposerais librement les librairies dans la section sources.

EDIT : Ce post est en délestage dans la section SWT, je m'étais trompé...

Bonjour,

Je ne suis pas très à l'aise avec les composants texte, mais ton post arrive en bas de page et j'ai pas envie qu'il se perde.

Si tu peux utiliser une approche MVC je trouve que c'est mieux, à condition de bien l'intégrer dans a librairie. En l'occurrence, étendre Document empêcherait d'utiliser les classes existantes du style HTMLDocument (si par exemple on veut éditer un gros fichier HTML). Le DocumentFilter n'a pas l'air d'être fait pour ça non plus.

Que penses-tu d'un Document wrapper, un peu dans le genre du TableSorter pour les JTable ? Le TableSorter si je me souviens bien est un TableModel qui délègue le stockage des données à un autre TableModel, et se concentre sur le tri des données par colonnes. Ca permet à l'utilisateur de trier n'importe quel type de TableModel.
Dans ton cas, ce serait un Document qui délègue le stockage à un autre Document et qui s'occupe de lire le ficher et de mémoriser les modifications. Je ne sais pas si c'est facile, difficile ou même faisable.

Merci pour ta réponse, je vais étudier cette possibilité.
En fait ce que je veux éviter c'est de devoir recoder toutes les fonctionnalités déjà existantes sur un tel type de composant ( gestion du clavier, des raccourcis, undo/redo, gestion du curseur etc. ), c'est pour cela que j'avais une idée avec le DocumentFilter.
Ayant des exams aux cours du soir au CNAM en fin de semaine, je doute avoir le temps de m'y mettre à fond cette semaine.

Je vous tiens au courant...

Bon j'ai étudié ( pas trop, j'ai des exams en ce moment ) la javadoc et j'en suis arrivé aux conclusions suivantes :
Etendre Document, PlainDocument, StyledDocument n'est pas vraiment adapté à mon cas.
Etendre JTextComponant aurait pu être intéressant, mais en m'inspirant du code source de JTextArea, j'ai remarqué que certaines méthode avaient une visibilité "package". Donc est-il possible d'étendre ce composant ? et si oui, comment ?
Dans le "how to" des composants texte de la javadoc, il est précisé que si l'on souhaite controler les modifications du texte, le plus s'imple est d'utiliser le DocumentFilter comme je l'avais imaginé au début.
Enfin dernière idée : étendre JTextArea, et surcharger ses méthodes de modifications. Cette idée me fait un peu peur ( à tord peut-être ) car mon composant n'affichant qu'une partie utile du fichier, je me demande bien comment cela va réagir lors des redimensionnements ou les ajouts de scrollbars par exemple...

Bon encore 3 jours à tenir ( exam de management lundi soir ), et je vais pouvoir reprendre le projet...
Après quelques brêves lectures, je compte étendre JTextArea et/ou JTextPane. S'il y a des remarques, ne pas hésiter ;)

Bonjour iohack,

Je suis également intéressé par une solution potentielle. As-tu pu résoudre ce problème ?

Merci d'avance pour ta réponse.

Bonjour et merci pour l'intérêt que vous portez à ce type de composant.

J'ai travaillé dessus il y a un mois environ.

Le package n'est pas terminé car cela demande énormément de rélexion. A chaque méthode (environ) je suis obligé de repenser le fonctionnement, cela entrainant méthodes et autres entités supplémentaires. En effet, au delà de la destination finale (une JTextArea hyper optimisée), je développe les outils nécessaires à une utilisation non graphique (la base) que ce soit en texte, binaire ou autre...
Je me retrouve donc à la base à traiter de trois catégories :
Documents textes, documents binaires, et documents organisés autrements (je code les comportement destinés au développeur souhaitant utiliser cet autre type de document).
La-dessus, j'ai rajouté une couche "fichier", permettant de gérer les documents sus-nommés sous forme de fichiers. Là-dessus j'ai été obligé de scinder encore deux catégories en fonction de la taille des fichiers : utilisation du package classique java.io pour les fichiers > à 2GO et java.nio pour les fichiers < à 2 GO.

Je vous avoue que la couche "graphique" (intégration dans des composants swing) n'est pas encore codée.

Ce projet n'est pas mort, j'aissaierai de vous tenir au courant.