Reprise du message précédent :
bha oui pour le moment ...  
 
il fait trop chuad : si j'essaye de réfléchir pour dire un truc, mon cerveau va planter ...

 
moi je quitte le boulot, ms je reviens pas avant demain. ça serait cool que tu m'donne ton avis. quand il fera moins chaud par exemple !

 
si un bean a un constructeur vide et uniquement ce constructeur là (enfin je parle uniquement de l'aspect constructeur hein !)

MMMMMMM je crois pas ...
allez un hop un petit tour vers la specif ...

je trouve pas !!!!!

j'ai pas trouvé dans la specif, j'ai pas trouvé dans thinking in java ... j'ai rien de mieux que ca à proposer :
 
http://developer.netscape.com/view [...] beans.html
 

 
et ça alors, ça vous parait correct ?

je comprend pas bien ce que tu veux faire ...
 
le plus simple c'est que pour chacun de tes objets "Donnée" (ligne d'une table), tu aies un javabean qui corresponde.
Ensuite tu auras d'autres objets "métiers" qui te permettront d'accéder à ces objets "Donnée" (en allant lire dans la BDD).
ensuite tu auras une couche de présentation qui affichera les objets "donnée" à l'écran.

 
Ouais. Mais tout ça doit avoir des relations "objet".
Genre, si j'ai un objet métier par table (je dois accèder à 13 tables), je devrais avoir une classe abstraite que chacun de ces objet métier implémente, non ? ça me permettrai par exemple, d'écrire une seule fois la méthode

 
Tu confonds les couches cher amis. Tu es au niveau persistence là. Justement j'ai bossé sur ce genre de problème hier. J'ai une GUI qui affiche les préférences de l'utilisateur. J'ai un bean qui correspond aux donnés que le user peut entrer et une classe "Helper" qui permet de lire/sauver ces données dans le fichier XML de conf.
 
Pour ta BDD tu peux effectivement faire une classe abstraite donnant par là les méthodes à utiliser pour sauver/effacer/updater/modifier.
 
Mais bon c'est un niveau d'abstraction encre supérieur. C'est  toi qui vois
 
Benou >>> Tu as raison, j'avais mal lu. En fait il FAUT un constructeur vide  mais rien n'empeche d'en avoir d'autre. Cependant je ne suis pas sur que ce soit une bonne idée d'en faire d'autre. Si tu les intègres dans un framework il y a fort à parier que le framework construirea toujours le bean avec le constructeur vide puisqu'il est sur de le trouver ...

je n'ai jamais dis que tu devais avoir 1 objet métier par table ...
Le but de tes objets métiers, c'est d'implémenter la logique de ton application, pas de mettre à disposition une série de méthode dont le seul but est de faire des requête.  
 
Essaye de bien définir les différents cas d'utilisation, essaye d'en faire ressortir les objets dont tu as besoins et les différentes étapes des scénarios (tu en déduieras les méthodes nécesaires à tes objets)

ouais, c'est bien ce qu'il me semblait ... mais je suis pas arrivé à trouver la preuve dans la specif des javabean quest ce qu'elle est mal faite !!!
 
Moi je créé quasiment toujours un constructeur supplémentaire pour pouvoir initialiser simplement les beans dans le cas où je m'en sers à la mimine ...

 
Mais, comment faire pour mettre les requêtes dans un fichier properties ?
sachant que je veux pas que le nom de mes tables et le nom de mes colones soit "en dur" dans les requêtes.
j'voudrais bien avoir un fichier properties du genre:
sql.nomtable=MATABLE
sql.macolone1=MACOLONE1
sql.macolone2=MACOLONE2
sql.requete=select (sql.macolone1),(sql.macolone2) from (sql.nomtable)
c pas mal ça non !?
'faut que j'utilise "MessageFormat" pour utiliser un truc comme ça, c ça ?

oui !? non !?

y a personne aujourd'hui ?

ouiiiiiiin, personnne y veut m'aider !!!!

ben euh
ouais si tu veux
mais bon
je vois pas trop l'interet de dissequer tes requetes comme ça, mais bon, stoi qui vois
messageformat
ou bien "+" ça marche aussi des fois

--greg-- a écrit a écrit : ben euh ouais si tu veux mais bon je vois pas trop l'interet de dissequer tes requetes comme ça, mais bon, stoi qui vois messageformat ou bien "+" ça marche aussi des fois

 
l'intérêt, c que les nom de mes tables varient souvent.
Si g 15 requêtes qui utilisent MATABLE, et qui MATABLE devient MONAUTRETABLE, ça m'évite de changer 15 trucs, je change juste le nom de la table.
Merci.

mouais mais bon en attendant tu te fais chier avec un systeme pas tres solide il me semble...
c pas la mort de faire un rechercher remplacer dans un fichier texte.. et puis je suppose que tes tables vont pas changer de nom pdt toute la durée de vie de l'appli ? y'a bien un moment ou le datamodel va se fixer?

--greg-- a écrit a écrit : mouais mais bon en attendant tu te fais chier avec un systeme pas tres solide il me semble... c pas la mort de faire un rechercher remplacer dans un fichier texte.. et puis je suppose que tes tables vont pas changer de nom pdt toute la durée de vie de l'appli ? y'a bien un moment ou le datamodel va se fixer?

 
Ouais, j'commence à me demander si t'as pas raison...