j'ai lu que clone() c'était mal.
mais là, j'ai l'impression que j'en ai vraiment besoin.
Ça fait un moment maintenant que je bosse sur un soft de gestion d'emploi du temps et donc je gère des évnènements représentés sur une grille, et là j'en suis au moment fatidique du drag n drop.
 
Les objets représentés sont assez compliqués, et je dois faire des testes  pendant le drag pour qu'on sache directement si le truc est déplacable ici où là.
 
Pour l'instant, j'ai fait un faux clone avec pas tout pour tester, cad que je clone l'objet, je le déplace et fais les tests dessus. Si au moment du lâcher les tests disent non, je fais rien, sinon, il faudrait que l'objet qu'on a déplacé se subtitue vvoyez.
 
En fait, je vois pas comment me passer de clone là. Enfin, plus généralement, je vois pas comment s'en passer quand on fait des trucs à base d'undo (ah si... j'avais lu sur le truc du GOF qu'il faut que chaque commande soit réversible... ouais mais non, là non   ) pour sauvegarder l'objet.
 
(Ah oui, je veux me passer de clone parce que j'ai la flemme d'implémenter clone() tellement y'a de trucs dans mon objet...)
 
donc là :
 
    * ma méthode est pas bonne je suis dans l'impasse ?
    * pas d'autre choix que d'implémenter clone() ?
    * il existe des libs qui inspectent des objets et peuvent les sauvegarder en mémoire (même si ça va à l'encontre de java, puiske les concepteurs ont pas prévu çà) ?
    * je serialize ?

juste pour info, dans un design "normal" tu ne clone l'objet métier *qu'après* le drop, pas au moment du drag, car tu ne sais pas encore si l'action va être réalisée, et tu sais pas à quel parfum le receveur va vouloir sa glace.

bah .. c'est pour cette raison que je clone avant moi...  
 
parce que là, le test existe déjà pour les instances de ce que je clone, et c'est assez compliqué (genre pas faisable à la main avec un if)
donc, je vois que 2 solutions
 

• dupliquer l'objet à dragger, le faire évoluer en fonction du drag, et faire les tests sur le nouvel objet "virtuel" dans quel cas on le garde si le drop est valide ou on le détruit sinon
• déplacer directement l'objet, en faisant les tests dessus, si le drop est validé rien à faire, mais sinon..? comment le faire reprendre son état d'origine ?

 
 
je viens de comprendre.
mes tests se font pendant le drag, je l'ai peut-être pas bien exprimé. ça pose pas de problème de perfs parce que le drag se fait sur une grille magnétisée et y'a pas un test par mouseMotion quoi  
 
le but c'est que le mec au moment du drag sache si c'est possible ou pas. d'où volonté de ma part de faire les tests sur un clone temporaire.
 
ça a quand même rapport avec l'undo nan ? c'est un truc qui m'a toujours effrayé, j'arrive toujours pas à voir comment ça se fait contrètement (je dis concrètement parce que j'arrive pas bien à estimer si en pratique, c'est possible d'avoir un objet command réversible pour chaque action utilisateur de l'appli.. enfin surement que quand on est fort ça se fait mais.. pfiooo).
Vous en faites vous ?

je vois pas pq t'as besoin d'un clone pour faire tes tests ?

bah... je vois pas comment faire sans en fait.
ça correspond à ma deuxième puce, les tests, je les fais sur quoi ? je fais évoluer l'objet, je fais les tests dessus, et après ? comment je peux le faire revenir dans l'état d'origine si finalement, le test dit que non ?

euh sans savoir de quoi tu parles, c'est un peu trop abstrait pour te donner une réponse

bah c'est une grille de gestion d'empois du temps. J'ai plein de contraintes de compatibilité des évènements. L'utilisateur a devant lui une grille et des évènements qui durent plus ou moins longtemps dessus (c'est des rectangles hein, rien de délirant)
 
Le mec fait un drag sur une des représentation graphique des évènements, et il essaye de le déplacer 2 heures plus loin. Il passe par +30, +60, +90, et +120 minutes comme étapes (la grille est magnétisée à 30 minutes admettons). Maintenant, j'aimerais faire les tests sur chaque transistion pour qu'il voie directement à l'écran si ce qu'il est en train de faire est possible.
 
Le test qui indique la cohérence de tout est gros. Pour l'instant, il regarde tous les évènements et regarde plein de choses à l'intérieur pour indiquer s'ils sont compatibles.
 
Ça veut dire que je dois déplacer non seulement la vue de l'évènement, mais aussi le modèle dans le temps pour faire mon test. Le problème étant de lui faire reprendre sa place si finalement le déplacement est annulé. Voilà.

euh bon tu me dis si je suis pas dans le bon, mais en admettons que tu ais un modele similaire à ceci
Event {
  Timestamp t;
}
 
toi tu modifies e.t avant de faire un test de "compatibilité" vis-a-vis d'une case candidate au drop?
genre

.. mais pourquoi tu le modifies? pourquoi ne fais pas un truc du genre:

?
 
(ça me parait plus sain, puisque dans l'absolu ton evenement ne DOIS pas être modifié tant que c'est pas validé par l'user, non ?

bah l'histoire c'est que pour l'instant ma méthode de test est générale, elle fait un test sur tous les évènements existant.
Alors, en effet, je pourrais faire quelque chose comme ça, à savoir un test sur un seul évènement, avec des modifs dessus.
 
Mais le problème c'est qu'il va faloir que je passe tout ce qui est suceptible d'être modifié en argument de ce test  : le temps de début, la durée mais aussi plein de choses.
 
en fait, si je passe tout en argument, autant encapsuler ça dans un nouvel objet => là ça s'apelle cloner je crois
 

ouais en fait, un cas particulier d'évènement c'est le cours universitaire, et alors là, ça y va les salles, les groupes, les étudiants pas du même groupe, les enseignants, le nombre de places dispo etc...

euh qd tu dragges ton event sur ton calendrier y'a autre chose que l'horaire qui change?

bah il peut aussi y avoir la durée (si c'est un drag d'étirement horizontal) et puis le nombre de groupes impliqués (étirement vertcial) aussi changement de journée (y'a tous les jours en ligne)  
 
mais bon, en fait, je vais m'orienter vers ce que tu proposes, ça me parraît plus propre.
merci de tes conseils.

chuis pas sur
(tu pourrais aussi avoir un object du genre ChangeRequest qui encapsule ces changements potentiels)

ouais ptet aussi ça.
(ouais, je me souviens aussi pourquoi j'avais eu l'idée de cloner : parce que le rendu graphique pendant le drag est un peu compliqué et que je faisais une vue du clone pour l'afficher. là je vais devoir me débrouiller à la main..)

il existe 2 grandes techniques pour le drag : changer le pointeur de souris ou déplacer une image transparente.  
 
Je te conseille la première, car tu n'as pas l'air très halaise sur la chose.

ouais.. enfin bon, déplacer une image y'aurait pas de problèmes mais là, déjà c'est magnétisé à un truc un peu évolué (en fait, le pas de la grille change en fonction des jours) donc même la vue est pas la même suivant là où on est
 
enfin bon, de toutes façons, c'est pas une appli commerciale que je fais là, et puis j'apprends alors si sapu un peu je ferai mieux le prochain coup.