Discussion :

[SeeNapse]

Bonjour à tous,

Un bout de code faut mieux qu'un long discours :

=== Côté serveur ===

public class Contact implements Serializable {

private String name;

// GETTER AND SETTER
}


=== Côté Client ===

// Demande d'instancier l'ejb Entity coté serveur
Contact monContact= DataBinding.createModel(Contact.class);
monContact.setName("Toto");

=== Infos supplémentaires ===
La classe DataBinding fais en sorte d'instancier le contact côté serveur. Il y'a donc une instance coté client ET serveur de mon objet

=== LE PROBLEME ===

Du fait qu'il s'agisse d'une entité, mon objet contact que j'ai instancié coté serveur est copié chez le client (d'ou la 2ième instance). Evidement, lorsque je modifie mon objet avec un setter côté client, la modification se fait coté client car il n'y a pas de référence directe entre mon objet du client et celui que le serveur a instancié.

Auriez vous une solution pour que lorsque je modifie mon objet côté client, les modification soit impacté directement à l'objet disponible sur le serveur ?


Merci énormément par avance

[a.snaps]

Auriez vous une solution pour que lorsque je modifie mon objet côté client, les modification soit impacté directement à l'objet disponible sur le serveur ?

Je pense que malheureusement cela soit impossible (sauf de wrapper ton objet dans un dynamic proxy, qui s'occuperait de faire le call qui suit à chacune de tes modifications)...
Le call qui suit donc:
Tu devrais implémenter un méthode mise à jour de ton instance via un SF ou SLSB, selon. Côté serveur, il faut merger l'instance détachée de ton entité avec le PersistenceContext. Une stratégie d'optimistic locking ne serait sans doute pas un luxe!
Alex

[martel]

tu utilises bien EJB3 ? si oui normalement avec ton EntityManagerFactory devrait pouvoir lors d'un "em.merge" reconnecter avec l'instance coté Serveur, et mettre a jour, mais je peux me tromper.

[SeeNapse]

Je te confirme bien que j'utilise EJB3, utiliser un em.merge revient normalement à faire comme le disais a.snaps un proxy qui s'occuperai des appels. J'avais déjà pensé au proxy mais je voulais voir si l'un de vous avait une meilleur idée

[a.snaps]

Tu n'as pas de PersistenceContext côté client. Le merge se fait côté serveur... Tu dois donc faire un appels à une méthode distante (remote call) à disons un Stateless SessionBean... Le EntityManagerFactory ne sert qu'à obtenir une session, et à nouveau est côté serveur.
Alex

PS: Si tu fais le dynamic proxy, le code m'intéresse... Par curiosité. Et de plus pourquoi cette stratégie? C'est quoi l'appli finale? C'est pas un peu tiré par les cheveux?

[SeeNapse]

L'objectif final est le développement d'un "framework" (gestion de la navigation, accès simplifier à la couche métier,...) indifférent à la techno de présentation (swing, jsf, etc...). Dans l'un des points à réaliser, il faut faire en sorte de gérer le databinding automatique d'un javabean classique avec un formulaire par exemple. Si ton application est par exemple en swing et que ton formulaire se résume à un wizard en plusieurs fenêtre, l'intérêt de gérer l'état des bean côté serveur est qu'il est très simple derrière de réaliser un traitement métier, et plein d'autres actions tout en ne tenant pas compte de la techno de présentation...

Bref, c'est pas tout simple à faire

[martel]

hum bizarre, je suis en train de lire le livre EJB3 de supinfo, chapitre 8 "développement des clients" , 8.1.2 vers la fin il dit ceci "La création du proxy est a la charge du conteneur et reste totalement transparent pour le client".

Ceci quelque soit le client (Client Riche ou par un Conteneur d'applications clientes). En faisant appel au Remote SessionBean prévu pour rafraishir du coté serveur.

Ou bien j'ai pas bien compris ce que voulais faire SeeNapse. Certe si c'est le cas désolé.

[SeeNapse]

Par proxy, je voulais parler de celui qui se charge de vérifier l'état des beans coté client et qui prends en charge toute la conversation client/serveur, mise à jours des différents bean

[martel]

Si il y a un bout de code pour que je puisse regarder, cela m'interesserais aussi

merci