Mapping composant graphique-Object

Bonjour,

Comment peut on faire le mapping entre object graphique (bouton ou autre) et entre un objet java développé?

Merci

Tu veux dire une de ses propriétés/accesseur/getter ? :?

Si c'est un objet ayant des propriétés FX via le binding.
Sinon via des listeners Java classiques (entre autres des PropertyChangeListener pour les beans classiques).

C'est pas clair comme question. :aie:

Merci pour ta réponse,

Voila, je m'explique plus.
Je parle de mapping objet fonctionnel-objet graphique.
Dans mon projet, j'ai différents objetcs comminiquant.
A chaque type d'objet fonctionnel, je veux assigner un type de graphique qui a tel et tel coordonnees (variables) et tel dimentions...
Est ce possible?

Je pense que la réponse vous ait donné, il faut chercher a comprendre le binding car tous les attributs des objets graphique en javafx on les assigné à des propriétés qui supportent cette technologie de binding, qui vont de permettre de faire ton mapping facilement. Il suffit de lier ces propriétés à tes objets java(mais essaye à les faire respecter dernier la méthode des Properties et Binding) , et si tu modifie tes objets java tes objets graphiques seront modifiés , il reste que tu sache les bien utiliser si tu veux que les changement soient synchrones ou asynchrones.
Vas y lire cet article de bouye sur le binding

Au cas où il te manque une chose tu peux aussi lire cet article anglais http://docs.oracle.com/javafx/2/bind...ub-binding.htm

Ce qu'il faut retenir c'est pour tout objet graphique javafx si tu vois par exemple un objet avec l'attribut cordonné X de type double, alors tu as surement pour cet objet ceci

Code:

---

public final void setX(double);public final double getX(); public final DoubleProperty XProperty();

---

ce dernier te permet de le bindé avec une autre propriété ou une expression contenant des variables

Note: c'est recommandé (mais pas obligatoire) de mettre chacune des 3 méthodes de même que la déclaration de la propriété en elle-même en final (mentionné plusieurs fois par Richard Bair probablement pour éviter des incohérences de comportement si une des méthodes ou la propriété est redéfinie par une classe fille).

Ok je viens de rectifier. Là si je comprend bien, c'est qu'on doit avoir dans la conscience que ces méthodes et la propriété en soit ne doivent pas entrer dans un contexte d'héritage, il va falloir déclarer d'autres et manipuler les méthodes publiques de la classe mère. Mais ma question c'est sur la propriété en soi, et si on la déclare privé y restera-t-il besoin aussi de la déclarer final dans le moment où il ne sera jamais vu dans les classe filles.

Déclarer final ne change rien à la visibilité en soit ; c'est bien sur public/private/protected et <package protected> qui changent la visibilité.

C'est juste que c'est fortement recommandé de déclarer tout ça en final puisque si on peut muter la propriété (et non pas sa valeur) ça peut créer toute sorte d'incohérence quand on commence à faire du binding : imagine qu'on bind la propriété A à un moment puis que la classe fille change la propriété A (ex : a = new SimpleBooleanProperty(); ), alors notre binding devient totalement invalide puisqu'il pointe sur une référence qui n'est plus utilisé par l'objet d'aucune manière. Pire, on est jamais averti du changement.

Même chose pour les getters et setters : si on permet de surcharger le setter on prend le risque la classe fille n'appelle jamais super.setA() et donc à quoi ça sert de se casser la tête à faire toute une API de binding si la propriété n'est jamais settée ?

Pareil pour le getter : pourquoi prendre le risque que getA() ne retourne pas la même chose que aProperty().get() ?

A noter qu'un problème d'incohérence se pose aussi quand on met des filtrages dans le setter (pour vérifier que les valeur fournies sont valides). Pour bien faire dans ce cas il faut que aProperty() retourne une ReadOnlyProperty. Si ce n'est pas le cas, on pourrait faire aProperty().set(valeurNonValide) en bypassant complêtement le filtrage mis dans setA() et ça c'est pas cool.

Merci très bien pour vos réponses,

J'ai bien vu ce que c'est que le binding, c'est très intéressant.
J'ai juste besoin de vos conseils pour voir la meilleure façon de voir les choses.
j'ai souvent le cas suivant: Une classe x (bean) qui a des attributs et une représentation graphique.
Est-t-il mieux: de faire:
Une même classe en mélangeant les attiributs d'ordre graphique et métier?
Une classe contenant une sous classe graphique (contenant la description graphique)??
Des classes distinctes en communications????