Discussion :

[joel.drigo]

Si tu as cette exception ici, c'est que listCustomerTmp est un itérateur de tableau de String (j'avais mal vu dans mon précédent post, je dis que c'est des String, alors qu'en fait ce sont des String[]).

Comme tu as déclaré listCustomerTemp en List<Client>, tu peux écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Iterator<Client> iterator = listCustomerTmp.iterator();

Pour le compilateur, tout est ok. Mais si à l'exécution tu as des String[] et pas des Client dans listCustomerTmp, ça ne plantera pas plus ici, parce c'est comme si on exécutait du :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Iterator iterator = listCustomerTmp.iterator();

ce qui est parfaitement exécutable.

Mais quand tu exécutes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Client client = iterator.next()

il faut que ce qui vient du next() soit du Client (en Java 1.4, il aurait fallut absolument écrire Client client = (Client)iterator.next();, ce qui aurait compilé), et c'est du String[] non castable en Client : d'où exception.

Le problème vient surement de ce que tu fais dans filetmp.ReadFileTmp() : la méthode doit retourner du Iterator<Client>, ou alors du Iterator tout court, et tu as un warning. Dans le second cas, dans la méthode tu dois retourner un Iterator obtenu sur une liste qui contient des String[]. Si ta méthode retourne bien du Iterator<Client>, alors tu as dû faire une autre bidouille à l'intérieur ReadFileTmp() pour que le compilateur laisse passer. Quel est le code de ReadFileTmp ? Au moins la déclaration de la méthode, de la variable que tu retournes, et la ligne avec le return ?

PS : je ne sais pas pourquoi tu t'obstines avec ton fichier texte... si c'est pour de la curiosité technique personnelle, c'est très bien pour apprendre, mais tu devrais faire ça quand ton projet est terminé. là il me semble que tu perds du temps sur un truc compliqué qui ne sert pas à grand chose (écrire dans un txt, pour le relire et l'écrire dans un xml) et en plus ça te fait trois séries d'I/O au lieu d'une : tu multiples par 3 le risque de plantage. J'ai l'impression que tu n'as pas bien lu ce que j'ai écrit au sujet du renommage de fichier, ou tu n'as rien à faire d'autre que d'utiliser ta méthode de sauvegarde en xml et des File.renameTo()).

[Jb_One73]

Alors j'ai localisé le problème et il se situe dans la classe FileTmp celle qui gère mes fichiers texte alors avant c'était sur la méthode WriteFileTmp et maintenant c'est sur la valeur qui est retournée par la méthode ReadFileTmp.
Jusqu'ici ça me semble logique dans le sens ou je fais de la généricité et que par conséquent il doit retourner le type que je lui indiquerai, cependant j'ai toujours des problèmes avec la mise en place.

Je vais mettre le code de la méthode ce sera plus parlant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
    /** LECTURE DU FICHIER TEMPORAIRE POUR MISE A JOUR DU FICHIER XML
     * @param sPath
     * @param iDimArray
     * @return 
     * @throws java.io.IOException */
    @SuppressWarnings("empty-statement")
    public List<T> ReadFileTmp (String sPath, int iDimArray) throws IOException{
 
        List<T> listTmp = new ArrayList();        
        String ligne = "";
        String sBalise = "";
 
        int i = 0;
 
        try{
 
            InputStream flux = new FileInputStream(sPath); 
            InputStreamReader lecture = new InputStreamReader(flux);
 
            try (BufferedReader buff = new BufferedReader(lecture)) {
                while ((ligne = buff.readLine())!=null){
 
                    /** Balise ? */
                    if (getBalise(ligne) == false){
                        listTmp.add((T) ligne);i++;
                    }else{sBalise = ligne;}
 
                    if (i == iDimArray) {
                        listTmp.add((T) sBalise);
                        i = 0;
                    }
                }
            }
        }		
        catch (Exception e){
            jop1.showMessageDialog(null, "Impossible de lire dans le fichier temporaire\n" +
                                         "Détail de l'erreur :\n" + e.toString(), "Erreur", JOptionPane.ERROR_MESSAGE);
        }
 
        return listTmp;
    }

Merci d'avance

[Jb_One73]

Désolé Joël ! J'avais pas vu que tu avais déjà posté un message avant le mien (le précédent à celui-ci) donc je vais juste répondre à ta dernière question :

PS : je ne sais pas pourquoi tu t'obstines avec ton fichier texte... si c'est pour de la curiosité technique personnelle, c'est très bien pour apprendre, mais tu devrais faire ça quand ton projet est terminé. là il me semble que tu perds du temps sur un truc compliqué qui ne sert pas à grand chose (écrire dans un txt, pour le relire et l'écrire dans un xml) et en plus ça te fait trois séries d'I/O au lieu d'une : tu multiples par 3 le risque de plantage. J'ai l'impression que tu n'as pas bien lu ce que j'ai écrit au sujet du renommage de fichier, ou tu n'as rien à faire d'autre que d'utiliser ta méthode de sauvegarde en xml et des File.renameTo()).

D'une je n'ai pas du tout compris ce que tu avais essayé de m'expliquer donc grosse erreur de ma part et deux j'ai perdu tellement de temps et reprendre des choses à droite et à gauche que maintenant j'ai peur de toucher à quelque chose, de tout casser et de repartir à 0.
Cette mésaventure d'avoir voulu essayé d'harmoniser mon code ma terriblement frustré et j'ai vraiment peur de faire une modif et que tout plante donc je suis d'accord avec toi et tu as parfaitement raison. Me restant très peu de temps pour finir ce projet je ne vais pas tenter le diable et poursuivre sur ce que j'ai déjà commencé, j'aurai eu plus de temps je l'aurai fait mail là ce n'est pas le cas.

Merci quand même Joël car en même temps je te fais perdre beaucoup de temps.

[joel.drigo]

Tu déclares :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<T> listTmp = new ArrayList();

On ne sait pas encore ce que c'est T (dans FileTmp).

Puis tu déclares :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String ligne = "";

ligne est donc du String. C'est définitif et irréfutable.

Puis dans le while suicant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while ((ligne = buff.readLine())!=null){

Tu vas mettre ligne, donc du String, en le castant en T (qu'on sait pas encore ce que c'est, donc qui peut être du n'importe quoi), pour le mettre dans un List<T>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

                        listTmp.add((T) ligne);i++;

Là, il y a un énorme warning de ton IDE qui te dit "attention : il y a un problème, parce que tu castes du String en T, sans tester que tu as à le droit de le faire" : dans mon Eclipse, c'est "Type safety : Unchecked cast from String to T". Et toi tu choisis d'ignorer ce warning.

Mais ton code ajoute toujours des String dans une liste, que tu vas toujours lire des String en essayant de les traiter comme des Client, ce qui est impossible.

Lorsque tu fais ta transformation d'écriture en client, il faut aussi que la transformation de la lecture soit faite de la même façon (ce qui t'oblige à écrire une méthode qui va pouvoir lire ton fichier texte, et lire chaque propriété pour les mettre dans une instance d'objet Client, en appelant ses méthode setxxx (setLastName(), etc...), par exemple avec un switch, ce qui va t'obligé à analyser les lignes lues pour retrouver le nom de la propriété et la valeur de la propriété, et également de déterminer là où s'arrête la liste de propriétés d'une instance de Client (puisque tu en as plusieurs dans un fichier texte, les unes derrières les autres).

Je ne sais pas comment tu écris ton xml, mais ça ne serait pas plus simple de virer le paramètre T de la méthode ReadFileTmp de lire le fichier sous forme de List<String> tout simplement ? Enfin, je dis ça, pour moi le plus simple, c'est que tu arrêtes de bosser sur ce truc pour le moment : ça ne sert à rien pour ton programme.

En gros, tu essaies d'inventer un nouveau format de fichier bancal pour essayer d'éviter de perdre des fichiers xml à la sauvegarde, alors que xml fait tout ça pour toi (sauvegarde des propriétés nommés dans un fichier texte (le xml c'est du texte)), mais, je te le redis et je te le répète, ça ne sert à rien, et en plus, tu n'a visiblement pas encore le niveau pour y arriver, donc tu perds inutilement du temps, et tu risques encore de passer pas mal de temps dessus avant que ça fonctionne complètement.

[joel.drigo]

Cette mésaventure d'avoir voulu essayé d'harmoniser mon code ma terriblement frustré et j'ai vraiment peur de faire une modif et que tout plante donc je suis d'accord avec toi et tu as parfaitement raison. Me restant très peu de temps pour finir ce projet je ne vais pas tenter le diable et poursuivre sur ce que j'ai déjà commencé, j'aurai eu plus de temps je l'aurai fait mail là ce n'est pas le cas.

Non, tu vas perdre plus de temps à faire fonctionner quelque chose qui ne sert à rien, sans peut-être même y arriver.

Si on revient à la base, tu dois avoir une méthode qui sauvegarde tes données dans du xml. Je ne sais pas comment était modéliser tes données avant, mais avec ta classe client ça devrait se résumé à un code du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 sauvegarder ( client, file )

ou client est de type Client et file de type File, un fichier xml.

Tu as bien ça non ? sous cette forme, ou sous une forme légèrement différente (file est peut être une variable de ta classe, et tu ne le passe pas systématiquement à la méthode), mais c'est pareil.

Dans le cas standard, c'est tout ce dont tu as besoin, et à la limite, si on ignore toute mention dans ton projet qui dit qu'il faut veiller à ce que les données ne soient pas perdues en cas de crash, ça suffit complètement.

Ensuite, il n'y a pas à tortillé : il existe tout un tas de conditions pour qu'on perde des données dans une application. Un immense géocroiseur qui tombe sur la terre, et c'est foutu. On ne peut que limiter les dégats. Et le plus simple pour limiter les dégats c'est d'éviter de perdre les données pendant qu'on les écrits. Donc de perdre le fichier qu'on est en train d'écrire. D'où la solution à base de renameTo() qui prend 2 ligne de code !!! Même en tapant avec 2 doigts, on doit bien pouvoir le faire en 3 minutes...

[Jb_One73]

Bon ! Ok ! Je vais abandonner le fichier texte et partir sur ce que tu m'as dit, je sais que si je n'y arrive pas je pourrais te poser des questions auxquelles tu me répondras (après je dis ça mais peut être pas mais ayant eu déjà pas mal déchange avec toi je reste confiant).
Je vais donc reprendre ta solution (il faut que je retrouve ton message mais je crois qu'il est dans ce post) et remettre tout à plat, j'avoue que j'ai la trouille mais plutôt que de perdre du temps là dessus et vu que tu insistes je vais donc m'y mettre de suite.

Merci Joël et à bientôt

[joel.drigo]

il faut que je retrouve ton message mais je crois qu'il est dans ce post)

http://www.developpez.net/forums/d15...t/#post8144355 (le 7)

Commence par la version simple :

En gros, si ton fichier s'appelle "fichier.xml", tu fais un truc comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
File file = new File("fichier.xml");
ecrireEnXmlDans(file);

Je parlais de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
File file = new File("fichier.xml");
File tmpfile = new File("fichier.xml.tmp");
ecrireEnXmlDans(tmpfile);
if ( file.exists() ) file.delete();
tmpFile.renameTo( file );

[Jb_One73]

Alors petit retour rapide, je viens de faire en 30mn ce que j'ai essayé de faire depuis ce matin ... j'ai donc perdu plus de 8h inutilement en cherchant a m'obstiné avec ces maudits fichiers texte (en même temps c'est de ma faute) alors je vais prendre sur moi et avancé au plus vite.

Un grand MERCI à toi et j'aurai dû t'écouter plus tôt