[Java] Exception lancée alors que ça devrais passer !

Recherche :

Dernière réponse

Sujet : [Java] Exception lancée alors que ça devrais passer !

--greg--

el_gringo a écrit a écrit :

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

:sol:

:hello:

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

--greg--

el_gringo a écrit a écrit :

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

:sol:

:hello:

El_gringo

--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...

--greg--

el_gringo a écrit a écrit :

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? :)

El_gringo

--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.

--greg--

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 ;)

El_gringo

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

El_gringo

y a personne aujourd'hui ?

El_gringo

oui !? non !?

El_gringo

greg@freestarthu a écrit a écrit :

oué enfin, déjà moi je mettrais pas du tout les requetes dans le code (mais dans un fichier properties par exempe)

...

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 ?

benou

DarkLord a écrit a écrit :

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 ...

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 ...

benou

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)

darklord

el_gringo a écrit a écrit :

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

Code :

/* méthode pour effacement des enregistrements sélectionnés par la requête passé en paramètre*/
int delete (String clauseWhere)

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 ...

El_gringo

benou a écrit a écrit :

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

Code :

/* méthode pour effacement des enregistrements sélectionnés par la requête passé en paramètre*/
int delete (String clauseWhere)

benou

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.

El_gringo

el_gringo a écrit a écrit :

D'après toi, je ferai mieux d'avoir 2 classes:
- une classe Utilisateur, qui contient le contenu d'un enregistrement dans la table utilisateur
- une classe SQLUtilisateur qui gère les requètes liées à la table Utilisateurs (avec par exemple, une méthode getOneUtilisateur (String clauseWhere) c ça ?

Et en fait, g une Quizaine de tables. Pouir chacune, je devrais faire 2 classes ? (une pour les données, une pour les méthodes business)
Et, si je fais ça, je vais faire une classe abstraite SQLTable qui sera étendue par tous les SQLUtilisateurs et autres, non ?
Cette classe abstraite aura une méthode :

Code :

abstract MonInterfaceEnregistrement getOneEnreg (String whereClause)

où MonInterfaceEnregistrement est une interface implémentée par les "Utilisateur" et autre classes qui contiennent les données d'un enregistrement d'une de mes tables (pas les méthodes business d'accès à la BD).
ça te parait correct ça ?

et ça alors, ça vous parait correct ?

benou

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

Citation :

A bean should have at least one "no-arg" constructor. It's OK to have other kinds of constructors, but a bean needs at least one constructor that has no parameters.

benou

:mad: je trouve pas !!!!!

benou

DarkLord a écrit a écrit :

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 ...

darklord

benou a écrit a écrit :

non

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

El_gringo

benou a écrit a écrit :

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 ! :hello:

benou

bha oui pour le moment ...

il fait trop chuad : si j'essaye de réfléchir pour dire un truc, mon cerveau va planter ...