Reprise du message précédent :

moi je te conseille de faire 2 classes séparées Client et Prospect, sans lien entre elles, quand il devient client, tu créés l'instance du Client. Y'a qui comme services sur compteClient ?

 
parce qu'un client est, par définition, connecté sur l'appli.
 

 
comme services?comment ca?

ça sert à quoi, on peut faire quoi avec un contrat ? y'a quoi comme méthodes dessus ?

http://ecrans.fr/L-empire-du-Bien,3325.html on a retrouvé Forrest Gump ...

le compteClient sert a regrouper les informations civiles du client.
Les methodes sont basiques : modification & suppression des données.

Apres, son utilisation n'est peut etre pas necessaire, je nesais pas.
Je sais juste que la connection et la creation d'un compte me pose probleme.

ouais, met tout sur la classe Client, ça sera mieux je pense.
 
moins y'a de classes, mieux c'est, une classe ça doit "peser son poids", c'est-à-dire apporter suffisamment de fonctionnalité pour mériter d'exister.

la base c'est que c'est une appli commerciale (reservation de voyages), donc on avait pensé a faire des comptes clients.

Sinon, pour la connection, tu vois ca comment ?
Le prospect rentre ses identifiants. Si ca marche, je créé l'instance du client?
comment je peux modéliser les liens "créé un compte" et "s'identifie" pour le prospect?  si je n'ai plus de classe compte.
c'est de la qu'elle venait a la base.

Ce qui me posait le plus probleme, c'est la suppression du compte. Le client doit pouvoir supprimer son compte. Sauf que je peux pas trop le faire s'il est identifie. donc probleme.

J'ai jamais eu a gerer differents utilisateurs, et je vois que c'est la merde

Et si je mets pas de classes compte, ca veut dire que la classe Client va directment dialoguer avec la classe de requetes qui fait les modifs en base.

bon, je viens d'y reflechir la.
J'avais au départ une classe abstraite Utilisateur donc dérive 3 classes :
Client, Propect et Voyagiste.

Si je mets pas de compte client, en fait je peux faire comme ca :

initialisation :
Utilisateur u = new Propect();

si le prospect veut s'identifier :
u = new Client();

s'il veut se deconnecter :
u=new Prospect();

c'est jouable comme ca, ou c'est moche a souhait?

par contre, me reste s'il veut supprimer son compte...
sachant que pour la suppression, il faut non seulement que ca le delogge, mais que ca supprime ses données en base.

est ce que je peux faire ca
u.supprimerCompte(){Requete.supprimer(idCompte);}
u=new Prospect();

?
au début je me disais que ca pouvait foutre la merde, non? le fait qu'il n'y ait plus de données en base pendant ne serait ce qu'une fraction de seconde mais que l'utilisateur existe encore sur l'appli...

ps : je pensais a un compte client parce que c'est plus pratique pour modeliser le lien "creer un compte" pour le prospect. Mais ca, c'est en partant sur la base du diagramme de UC. Or, il faut peut etre que je m'en detache, sinon je risque de faire trop de classes, qui servirait pas forcement...

et dernz

Oublie un peu la modélisation, tu la fera après, de toutes façon y'a des trucs qui ne peuvent pas apparaitre sur un diagramme UML, ou en tout cas pas à un prix raisonnable.
 
Le concept qui te manque je pense c'est celui de session. c'est le concept sous-jacent au problème de l'authentification du client, il n'est authentifié que pour une session qui est une série d'interactions avec le système. quand il s'identifie, il démarre une session.
 
donc tu as une instance de client qui existe depuis la conversion du prospect. quand l'utilisateur saisit ses identifiants, il créé une session, qui est rattaché à l'instance de Client.
Si le client veut détruire son compte, tu détruits l'instance de Client et la session rattaché.

la destruction du compte doit entrainer la destruction des données en base.
 
par contre, pour faire la modelisation apres, je voudrais bien.Mias mon prof est pas d'accord...

oui, le seul truc que tu stockes en base, c'est l'instance du Client.
La session ça n'y va pas.
 
 

il fait chier avec ses jointures qui servent à rien

Pas terrible surtout. Ton truc est équivalent à:

Ce qui est nettement plus propre, mais pas sûr que ce soit ce que tu voulais faire.
Ce serait pas plutôt le contraire:
 

?
Je suis p-ê à coté de la plaque, mais de toute façon, je trouve un peu étonnant que tu aies à faire ça.
Si je ne m'abuse, tu es en train d'écrire une requête à la main, or dans 99% des cas, avec une couche de mapping objet, tu ne devrais pas avoir à le faire, au moins lors de la conception (je demande confirmation auprès de Lam's, mais c'est mon impression perso). Peut-être que le modèle est améliorable ?

Non, ta première interprêtation est fausse, je sépare bien mon merdier par des virgules.
 
Et on peut pas binder un tableau sur un IN en EJB QL, donc il faut bidouiller.

Non. Un client peut avoir plusieurs comptes. Et même si ce n'était pas le cas, c'est une mauvaise idée. Tu vas te retrouver avec tout le code de gestion du compte dans ta classe client, autant arrêter de faire de l'objet tout de suite.

Hmmm, j'aurais plutôt associé les infos civiles à une classe individu dont dérivent client et prospect. CompteClient sert à gérer les infos du compte lui même, à savoir les transactions de réservations, les droits associés à ce client, ses goûts etc.
Ensuite, une classe d'attribution de droits indique, pour chaque classe d'individu, tous les droits associés. Elle est requêtée au moment de la connexion. Elle peut par exemple indiquer qu'un individu de type commercial a le droit de se connecter à un compte client. L'avantage, c'est qu'ainsi, tu peux créer un certains nombre de types d'individus différerents et gérer leurs attributions finement.

Ah, je ne connais pas les EJB.
Par contre, effectivement, j'ai mal lu ton code. Il est équivalent à :

Ce qui à mon sens est plus lisible (et accessoirement plus rapide).

mouais, bof.

Je viens de lire presque tous les xkcd...

c'est faisable ça, en vrai?
ou comme écran de veille?

Tu es à mi-chemin entre le design pattern State (un "Utilisateur" peut être Client, ou il peut être Prospect). Et le Strategy pattern (un utilisateur de ton système attaque une page-web produit en tant que prospect ou en tant que client). Et tu sais quoi ? Ca tombe bien parce que c'est les deux s'implémentent vaguement de la même façon.

L'héritage (ou spécialisation) se prête bien à ce type de choses là uniquement quand la spécialisation ne change pas pendant la durée de vie de ton objet. Si le mec doit se reconnecter entre 2 changements d'état, tu peux effectivement faire ça simplement:

Sinon, utilise un objet pour représenter l'état:

(et oui, le <#> représente la composition)

Tiens, Lam's, puisque tu traines par ici, jette un oeil à l'intro de la spec du format Jpeg XR. Ca a beau être du Microsoft, il m'a l'air de parfaitement couvrir les besoins  photographiques actuels.
http://forum.hardware.fr/hfr/Photo [...] 6845_1.htm

 
elle est très bien ma banlieue
 

 
C'est du temporaire, juste pour quelques mois

Je connais un peu (quoique, perso, j'aurais utilisé des matrices de 4x4 pour les composants DC aussi, et récursivement jusqu'à couvrir toute l'image. Mais je suppose que les chercheurs de Microsoft ont dû y penser, et ont dû vouloir garder la qualité du JPEG qui est de pouvoir être écrit ligne par ligne, pour les images gigantesques).

Ca existe, les outils de monitoring réseau, comme ça ? Tu visualises le réseau via un graphe de ce type, tu double-cliques sur une machine et tu as toutes les infos que tu veux dessus en temps réel.

   
et en branchant un deuxieme moniteur, en faisant plusieurs machines virtuelles et en leur mettant de gentils bots ouvreurs de mails/visiteurs de site porno/etc... et en les reliant a internet, ya moyen d'avoir la même chose?

http://forum.doctissimo.fr/vieprat [...] htm#t18531
 
je me demande si ça marche là bas comme troll

En tout cas, je ne comprends pas pourquoi les industriels de l'image, les Kodak, Fuji, Canon, Nikon & co ne se sont pas mis d'accord pour se pencher sur un nouveau format, dont le besoin est criant. Il a fallu que crosoft s'y colle. Pareil pour le RAW, c'est Adobe qui a sorti un format ouvert. Il faut croire que la concurrence entre compgnies de l'image est telle qu'ils ne se mettent d'accord sur rien, même pas sur un format d'échange de fichier.

Y'a moyen de fonder une boiîte en tout cas. Un truc comme BigBrother Unlimited, le produit s'appellerai Eye, d'où le nom complet BigBrother's Eye.

Bon, mon proprio est censé venir me filer un débouche-évier, mais vu l'état de "rangement" de l'apparte, je crois que je vais aller le chercher moi-même.

T'as vu des modèles intéressants ?
 

T'y crois vraiment à ça ?

pourquoi quitter la France: http://yahoo.anxa.com/rencontres-a [...] ur.asp?v=0
 
 la suisse est devant

Ca existe (je bossais sur ce type de truc). Le problème, c'est que c'est nickel pour faire des démos, mais en vrai, ça ne sert à rien: les seules personnes qui ont besoin de ce type d'outil (ou du moins, qui ont le budget pour en acheter) ont tellement de machines à gérer qu'un affichage en graphe (ou même en arbre) est inutilisable.

Notre outil faisait tourner des agents SNMP, et allait aussi taper sur les routeurs en ligne de commande (pour récupérer les tables BGP, RIP et OSPF): il retrouvait les tables de routage, il recalculait les adresses IP des machines et de leurs interfaces, et il créait des connexions entre interfaces sur le même sous-réseau (ou en cas de réseau avec plusieurs machines branchées dessus, il mettait carrément une jolie icône avec le masque du réseau). On avait un super toolkit d'affichage (Tom Sawyer), et ça nous a fait vendre plein de binious. Mais en vrai, c'est inutile. (c'est un peu comme une super feature que j'avais, et qui affichait les stats de QoS et d'utilisation pour chaque routeur, directement via une page web intégrée dans notre IHM: splendide, super-vendeur, mais complètement inutile dans la vie de tous les jours).

[/WC-NET]

 
elle en fait quoi de son appart    ?

Elle le prête à sa mère

Mais pourquoi vous voulez un camescope ? Madame a du retard ?  
 
Pis je trouve bizarre l'ordre dans lequel vous faites les choses. En théorie, c'est:
   test clearblue - monospace - poussette loola - camescope - maison - chien.
Là, vous faites:
   maison - camescope - monospace. Et ensuite le chien et le test clearblue ?
 
 
NTK:
   http://tempsreel.nouvelobs.com/act [...] llard.html

moi j'adore les fonctions de chef. on en avait une aussi dans ma boite précédente (des camemberts qui s'actualisaient pendant le calcul).
 
Sur mon site y'a plein de monde qui veut que je mette les trajets des entrainements, probablement des gens qui ont jamais été se faire chier sur le site de nike+ à cliquer comme des cons sur la carte pendant 3h à scroller dans tous les sens (si tu dézomme pour mettre 10km sur l'écran, y'a peu de chances que tu vois encore ton chemin), voir que leur chemin de terre n'y est pas, pas pouvoir démarquer précisément la partie chronométrée du trajet, et pas savoir que foutre de la différence de distance entre celle mesurée sur la carte et celle du podomètre. Pourtant sur un screenshot, c'est la classe internationale les parcours.

http://fr.youtube.com/watch?v=b9du5U6Nk4U
 
et sinon bah
on attendait que femme décroche son concours d'instit mais comme après 45 ans femme ne sera plus fertile, il faut que je prenne les choses en main pour lui expliquer  
 
donc maison  
comme belle maman habite loin => nouvelle voiture
if enfant in [2010] then mariage in [2009] /* cochonne né en 80, truc des 30 ans */
if mariage + enfant then camescope