Re: Aide pour une stratégie de programmation.

From	Yliur <yliur@free.fr>
Newsgroups	fr.comp.lang.java
Subject	Re: Aide pour une stratégie de programmation.
Date	2017-11-14 12:27 +0100
Organization	Groupes francophones par TrigoFACILE
Message-ID	<20171114122759.223fae94@free.fr> (permalink)
References	(2 earlier) <5a03af3a$0$7158$426a74cc@news.free.fr> <20171109091546.54256f71@free.fr> <5a06ff9f$0$3443$426a34cc@news.free.fr> <20171111183357.7277d116@free.fr> <5a0a6560$0$3841$426a74cc@news.free.fr>

Show all headers | View raw

>>> (JTestPane) ((Chapter) (vector.getChapter())).getMainText() =
>>> jtextPane;
>>
>> Là je ne vois pas bien ce que tu fais : la ligne ci-dessus ne semble
>> pas être du code qui fonctionne (tu ne peux pas affecter jtextpane au
>> résultat de getMainText()).
>
> Si. Normalement ça doit marcher. La méthode getMainText() c'est moi
> qui l'ai inventée. C'est celle qui renverra un JTextPane de l'objet
> Chapter. La question que je me posais était de savoir si le fait de
> mettre le symbole = permettait de faire le lien entre la
> représentation graphique et le JTextPane dans le Chapter du Vector.
> Je pense qque oui mais je n'en suis pas sûr. Sinon comment fait-on
> pour dupliquer un objet déjà? On emploi la méthode clone()?

Non, ça ne peut pas marcher.

Une forme valable c'est ça (on associe une valeur à un nom) :
    nomVariable = valeur ;

Une autre forme possible (on passe la valeur à une fonction ; laquelle
pourra faire elle-même une association pour stocker la valeur quelque
part) :
    fonction (valeur) ;
par exemple :
    chapter.setMainText (texte) ;
avec un corps de setMainText de cette forme :
    this.mainText = texte ;

Par contre tu ne peux pas utiliser cette forme :
    getMainText() = texte ;
parce que getMainText() renvoie une valeur et donc c'est de la forme
    valeur = valeur ;
ce qui n'est pas possible.


>> Déjà il faut choisir s'il existe un composant graphique par
>> chapitre. À mon avis ça ne sert à rien et ça complique les choses.
>
> Je pense que c'est quand-même la solution que je vais retenir car
> c'est celle du logiciel d'origine et elle est très ergonomique. Ce
> programme est très bien pensé. Dommage qu'il soit complètement
> buggé...

(note qu'il semble y avoir un peu d'activité sur le site de ce
logiciel ; après ça n'a pas l'air d'avancer rapidement...)

Là je pense qu'on ne s'est pas bien compris : je n'ai rien contre
l'ergonomie du logiciel que tu cites et je parle bien de reproduire
la même interface. Mais pour ça il n'est pas obligatoire de créer un
composant graphique (ou plusieurs) par chapitre.

En clair il y a deux solutions...

La première consiste à effectivement tout représenter dans les
composants graphiques. Par exemple stocker le texte de chaque chapitre
dans un JTextPane. Ça a l'air simple à réaliser, la correspondance
entre les données et leur représentation graphique est simple à
comprendre, par contre ça risque de compliquer le développement futur
du logiciel.

La seconde consiste à représenter d'un côté les données (chapitres,
textes, notes, personnages, ...) dans des classes qui n'ont aucun lien
avec l'interface graphique, et de l'autre à représenter l'interface
graphique. Cette solution nécessite un peu plus de réflexion, il y a un
peu plus de classes et il faut synchroniser les données et l'interface,
mais elle est souvent plus simple à comprendre quand le logiciel
grossit.

Ces deux solutions concernent uniquement l'organisation du code et la
conception du logiciel, elles n'ont pas d'impact sur son ergonomie et
sur la manière dont l'utilisateur manipulera les données.

De manière générale, je pense qu'il est plus facile de penser un
programme en raisonnant sur ses données et fonctionnalités, l'interface
n'étant que la traduction d'une partie de ces fonctionnalités
(d'autres pourraient être l'indexation/recherche, la création de pages
regroupant les données sous une autre forme, ...). Donc je penche pour
la seconde solution. C'est un peu plus de travail et d'explications mais
je pense que ça en vaut vraiment la peine Et dès que tu vas vouloir
sortir des fonctionnalités de base (l'édition des informations par
chapitre) ça va être plus simple.

Là il faut choisir l'une ou l'autre option (la plus simple ou celle qui
nécessite plus d'effort mais qui est mieux rangés à plus long terme).
Sinon on ne se comprend pas bien et les explications sont plus
compliquées (dans le dernier échange on est à cheval entre les deux, on
ne s'est pas bien compris).

Et en fait en relisant mon message et en jetant un œil sur les captures
d'écran de Plume Creator je suis bien sûr que tu vas être ennuyé très
rapidement quand tu vas vouloir faire des choses un tout petit peu plus
avancées, comme l'affichage d'informations sous une autre forme, la vue
qui semble servir à comparer les textes de deux chapitres, la
mini-carte, ... À ce moment si tu n'as pas très clairement distingué
les données manipulées des composants graphiques tu vas bien te prendre
la tête.

Donc à moins que tu aies une objection majeure, je vais un peu attendre
que tu décides de me faire confiance sur cette partie puis poursuivre
mon explication dans ce sens ;) .

Et ne t'inquiète pas, ça n'empêche absolument pas de reproduire le
comportement du logiciel d'origine ; le fait que tu en doutes (et
d'autres remarques, comme la question sur List/JList) me semble être le
signe que tu ne parviens pas encore bien à distinguer les données de
l'appli de leur représentation dans les discussions, à mon avis ce sera
beaucoup plus clair avec la deuxième solution.

Pour l'instant je ne réponds pas à ta question sur la duplication de
données parce que je pense qu'elle est issue de l'échange embrouillée
et qu'elle ne paraît pas nécessaire.

Pareil pour la question sur List/JList.


> Oui car c'est la même chose que pour les menus. Mais je manque
> d'expérience dans le traitement des évènements. A part les menus je ne
> sais pas trop comment ça se déclare, même si je vois à peu près
> comment faire en prenant l'exemple des menus.

Ça devrait fonctionner comme tu l'as fait pour les menus, la gestion des
événements n'est pas très complexe à la base :
    - Une classe doit servir d'écouteur (implémenter XXXListener). Elle
      contient une ou plusieurs méthodes traitant des événements (ce
      qu'il faut faire quand un événement survient). Tu peux avoir une
      classe pour ça ou bien opter pour une solution plus simple qui
      consiste à utiliser ta fenêtre pour réaliser cette classe (c'est
      donc elle qui contient les méthodes de traitement des événements).
      C'est une solution acceptable tant que la gestion des événements
      n'est pas très complexe. Il peut aussi s'agir d'un onglet,
      panneau ou autre si tu as créé une classe pour ça et que les
      événements le concernent.
    - Une ou plusieurs méthodes doivent être écrites pour traiter les
      événements qui t'intéressent.
    - La classe doit être enregistrée comme écouteur sur le composant,
      pour indiquer qu'elle veut recevoir les événements. Ça se fait
      avec une fonction du type addXXXListener sur le composant source
      des événements (bouton, ...).
      Pour déterminer les événements interceptables sur un composant,
      tu cherches donc dans la doc (tu as toujours la doc pas loin ?)
      les méthodes addXXXListener de ce composant et tu regardes
      l'interface à implémenter pour la liste des événements possibles
      (par exemple si on écoute les événements de souris
      (MouseListener) il y a plusieurs événements comme mouseClicked,
      mouseExited, ...).

Tout ça doit ressembler pas mal à ce que tu as fait avec les menus.


Voilà pour cette fois :) . Il faut vraiment choisir une des deux
solutions de conception, sinon les explications vont rester confuses.
Tu verras qu'avec l'une ou l'autre ce sera plus simple de discuter et
de s'y retrouver dans les concepts ;) . Et donc à mon avis si tu ne
choisi pas la deuxième tu vas être encore plus embrouillé.

Back to fr.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-03 16:16 +0000
  Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-07 15:03 +0100
    Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-09 01:28 +0000
      Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-09 09:15 +0100
        Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-11 13:48 +0000
          Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-11 18:33 +0100
            Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-14 03:39 +0000
              Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-14 12:27 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-15 03:48 +0000
                Re: Aide pour une stratégie de programmation. Samuel DEVULDER <samuel-dot-devulder@laposte-dot-net.invalid> - 2017-11-15 08:44 +0100
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-15 09:10 +0100
                Re: Aide pour une stratégie de programmation. Samuel DEVULDER <samuel-dot-devulder@laposte-dot-net.invalid> - 2017-11-15 09:31 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-17 01:45 +0000
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-15 04:45 +0000
                Re: Aide pour une stratégie de programmation. Samuel DEVULDER <samuel-dot-devulder@laposte-dot-net.invalid> - 2017-11-15 09:44 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-17 01:33 +0000
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-15 09:57 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-17 01:24 +0000
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-17 08:32 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-19 06:08 +0000
                Re: Aide pour une stratégie de programmation. Samuel DEVULDER <samuel-dot-devulder@laposte-dot-net.invalid> - 2017-11-19 08:38 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-19 12:27 +0000
                Re: Aide pour une stratégie de programmation. Samuel DEVULDER <samuel-dot-devulder@laposte-dot-net.invalid> - 2017-11-20 01:33 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-20 20:51 +0000
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-19 10:13 +0100
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-19 10:51 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-19 12:20 +0000
                Re: Aide pour une stratégie de programmation. Yliur <yliur@free.fr> - 2017-11-19 14:42 +0100
                Re: Aide pour une stratégie de programmation. bloiiing <bloiiing.invalid@yahoo.com> - 2017-11-19 15:55 +0000

csiph-web