[firePropertyChange] semble ne pas fonctionner ?

bonsoir à tous,
j'ai sûrement pas bien compris l'effet de cette méthode, pouvez-vous m'éclairer ou m'aiguiller ... :?:
voilà ce que je fais :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// dans la classe (extends JMenu) je déclare : protected PropertyChangeEvent changement; // dans le constructeur : this.addPropertyChangeListener(new PropertyChangeListener(){ public void propertyChange(PropertyChangeEvent evt) { changement = evt; } }); this.putClientProperty("name", "jmenu_à_Toto"); // puis, comme j'aimerai voir Jmenu [jmenu_à_Toto,0,0,0X0,invalid,etc...] // lorsque je System.out.print(this); , je fais : firePropertyChange( changement.getPropertyName(), changement.getOldValue(), changement.getNewValue()); // et je peut seulement lire Jmenu [ ,0,0,0X0,invalid,etc...]

---

bon, alors est-ce-que firePropertyChange n'est pas une façon d'appeler
setName("jmenu_à_Toto"); :?: :?: :?:

merci de vos réponse ...

Normalement ceci :

Code:

---

1 2	putClientProperty("name", "jmenu_à_Toto");

---

est équivalent à celà :

Code:

---

1 2	setName("jmenu_à_Toto");

---

Tu n'as donc pas besoin de faire le firePropertyChange() manuellement.

Citation:

---

Changes to client properties are reported with PropertyChange events. The name of the property (for the sake of PropertyChange events) is key.toString().

---

Ensuite il faudrait peut-être afficher event.getPropertyName() ou qqchose d'autre dans la gestion de l'évènement pour s'en rendre compte.

Enfin la propriété n'est changée et l'évènement n'est lancé que si la nouvelle valeur est différente de l'ancienne. Si les valeurs sont identiques aucun évènement n'est lancé.

merci bouye,
j'essayais firePropertyChange car justement putClientProperty("toto");
n'a pas l'effet voulu.
en fait :
this.putClientProperty("name", "toto");
this.getClentProperty("name"); le donne bien "toto" mais :
this.getName(); me donne null ... :?:
et this.paramString(); n'affiche pas non plus le nom dans les paramètres :?:
no comprendo .... t'as une idée :?

Arf autant/au temps pour moi.
Je viens d'aller dans les sources de Component, comme c'est du code assez ancien (d'avant les beans) ; le nom du composant n'est en aucun cas lié à la propriété cliente name :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void setName(String name) { String oldName; synchronized(this) { oldName = this.name; this.name = name; nameExplicitlySet = true; } firePropertyChange("name", oldName, name); }

---

Donc effectivement ces code-là ne font pas la même chose.

ok, alors je dois implementer une méthode équivalente à putClientProperty(object, object) mais pour les propriété du JComponent où je suis miro et elle existe déjà ?????? :?:
d'ailleurs, à quoi sert ClientProperty :?:
ah ok hervé... je lis en même temps ... c'est ce que je constate ...
ClientProperty est utilisée par quoi ?
quelle est l'interface où sont stockés ces constantes name, text etc ... :?:

Le plus simple serait de faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

/** @inheritDoc */ @Override public void setName(String value) { putClientProperty("name", value); }   /**@inheritDoc */ @Override public String getName() { return (String)getClientProperty("name"); }

---

Ensuite :

Citation:

---

public final void putClientProperty(Object key, Object value)

Adds an arbitrary key/value "client property" to this component.
The get/putClientProperty methods provide access to a small per-instance hashtable. Callers can use get/putClientProperty to annotate components that were created by another module. For example, a layout manager might store per child constraints this way. For example:

componentA.putClientProperty("to the left of", componentB);
If value is null this method will remove the property. Changes to client properties are reported with PropertyChange events. The name of the property (for the sake of PropertyChange events) is key.toString().
The clientProperty dictionary is not intended to support large scale extensions to JComponent nor should be it considered an alternative to subclassing when designing a new component.

---

Perso j'utilise très souvent putClientProperty() et getClientProperty() mais pour changer mes propres propriétés, et j'utilise plutôt les accesseurs pour les propriétés pre-existantes. Dans mes objets non-composants graphique je délègue à un PropertyChangeSupport qui fait la même chose.

Et pour finir la valeur du nom est stockée dans le membre name de la classe Component (l'un des ancêtres de JMenu).

re bouye,

Citation:

---

Perso j'utilise très souvent putClientProperty() et getClientProperty() mais pour changer mes propres propriétés, et j'utilise plutôt les accesseurs pour les propriétés pre-existantes.

---

c'est précisemment ce que je veut faire ... du moins pour la première partie : là je vais te monopolisé STP, :P
en fait il faut que je redefinisse putClientProperty pour qu'elle appelle setName ou toute méthode set correspondant à la propriété ? (setText pour "text" ... etc
ce que je voulais dire tout à l'heure, c'est la propriété "name", où est elle stockée, c'est bien une constante du style static final String ? = "name" dans une interface ... non :?: :?:
j'aimerai bien faire une interface de propriétés avec ces constantes, ou réutiliser celle qui existe ...

Citation:

---

en fait il faut que je redefinisse putClientProperty pour qu'elle appelle setName ou toute méthode set correspondant à la propriété ? (setText pour "text" ... etc

---

Je n'ai pas très bien compris (ce n'est pas clairement expliqué) mais en gros ca correspond au 2 méthodes surchargée que j'ai donné dans mon poste précédent.

Sinon tu ne vas effectivement surcharger que 2 méthodes (getClientProperty() et putClientProperty()) mais tu vas avoir des tonnes et des tonnes de comparaison dans chacune des 2 ; histoire de savoir s'il te faut appeler un accesseur "natif" ou alors super.getClientProperty() et super.putClientProperty(). M'enfin de toute manière chacune des 2 approches a des défauts et ca va etre dur de ne pas dupliquer du code dans chacun des composants. Je dirai que tu peux dans une certains mesure utiliser une classe externe helper pour centraliser les tests :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class PropertyAccessHelper { public static boolean putClientProperty(Component component, String property, Object value) { if (property.equals("name")) { component.setName(name); return true; } .... return false; }   // C'est un peu moins evident a faire pour le getClientProperty pour indiquer si on a put utiliser un accesseur "natif" a cause de la valeur de retour.   ... }

---

Et dans ton composant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

..... /** @inheritDoc   */ @Override putClientProperty(String property, Object value) { if (!PropertyAccessHelper.putClientProperty(this, property, value)) { super.putClientProperty(property, value); } }   ...

---

Citation:

---

ce que je voulais dire tout à l'heure, c'est la propriété "name", où est elle stockée, c'est bien une constante du style static final String ? = "name" dans une interface ... non
j'aimerai bien faire une interface de propriétés avec ces constantes, ou réutiliser celle qui existe ...

---

Hélas apparement non ; il faudrai fouiller dans les sources de l'API pour voir quelles valeurs sont utilisées ou si Gfx repasse il pourra peut-être répondre de manière plus détaillée. Mais pas mal des propriétés de base ne semble pas être définies dans des constantes mais écrites en dur dans le code (beurk !).

ex : JFormattedTextField utilise la propriéte "value". Et tous les composants utilisent évidement les propriétés "name", "enabled", etc.....

Moi j'ai tendance à définir des constantes finales, statiques et publiques ; voir mon code pour un ImagePanel.

J'ai pensé a un moment faire une interface centralisée comme toi puis je me suis dit que ca serait mieux (dans mon cas) de ne définir ces constantes que dans la classe où elles sont utilisées et de préfixer la valeur de chaque constante par le nom de la classe.

ok, bouye merci,
j'opte plutôt pour une interface, çà m'entraînera toujours à manipuler les interfaces ...
une interface donc qui étend PropertyChangeListener de sorte que mon composant (this, étend JMenu par exemple) qui l'implemente m'autorise à ce genre de choses :

Code:

---

1 2 3 4

this.addPropertyChangeListener(this); this.putClientProperty( uneCleDeInterface,uneValeurDonnée);

---

et ailleurs dans la classe j'ai donc obligation d'implementer :

Code:

---

1 2 3 4 5 6 7

public void propertyChange(PropertyChangeEvent evt) { String propriete = evt.getPropertyName(); if(propriete.equals("name")) this.setName(evt.getNewValue() + ""); // ou Interface_CLE_NOM par exemple ... if(propriete.equals("text")) this.setText(evt.getNewValue() + ""); }

---

merci de me dire si un gros defaut te saute au yeux, on a tellement de possibilité qu'on s'y perd sans des bases solides de conceptions ..
merci pour toutes tes réponses aussi .
A+ bouye.

ps: on truc m'échappe, les méthodes natives que tu évoquais ne se chargent jamais d'appeller la méthode set correspondante sur le composant, exemple :

Code:

---

1 2	super.putClientProperty("name", value);

---

à aucun moment n'appelle setName(), mais plutôt l'inverse, ainsi je me demande quelle classe de l'api, quelles méthodes lisent cette propriété nécessairement pour leur fonctionnement ?

Je ne suis pas sur qu'on se soit super-bien compris... mais bon c'est pas trop grave. Note : en parlant d'accesseur natifs je parlais des methodes setName(), setEnabled(), etc... telles qu'elles sont définies actuellement dans Component c'est à dire que ce sont des wrappers d'accès à des membres plutot que des méthodes de convenance qui appeleraient putClientProperty() par en dessous.

La redéfinition de setName() et getName() n'est utile que 1) si on redéfinie les 2 méthodes (redéfinir juste le setName() ne suffit pas); 2) si nul part il y a un acces direct au membre name de la classe Component (difficile à vérifier).

Bon ceci dit je vais arrêter de regarder le code source de Component car c'est assez moche à voir entre les accès direct, la valeurs des propriétés écrites en dur, les appels à des méthode deprecated (ex : setEnabled(boolean value) appelle enable(boolean value)) et des trucs plus ou moins redondants pour la gestion des évènement en général et la propagation des changements de propriétés en particulier... Dommage que le besoin de compatibilité ne leur permette pas un grand nettoyage par le vide ; y en aurait bien besoin...

JComponent est une classe bien mieux écrite.

Citation:

---

Je ne suis pas sur qu'on se soit super-bien compris...

---

mais t'inquiètes pas çà me fait avancer ...
on comprend de prime abord que ce qu'on peut assimiler parce qu'on a au préalable appris les clés qui permettent de décoder, faut que çà fasse son chemin ...
je me cite moi même :

Citation:

---

si un gros defaut te/me saute au yeux

---

et j'écrivais

Citation:

---

this.addPropertyChangeListener(this);

---

tout à fais inutile, puisque ma petite interface étend PropertyChangeListener, pourquoi l'ajouter à elle-même... à zapper :!:

ce que je veut faire, c'est donc développer des interfaces, des classes qui étendent des JComponents, qui me permettraientt d'écrire en quelques lignes dans toutes mes applis le code nécessaire à l'instanciation d'un JMenuBar et de tous ses JMenus, et JMenuItems, pour éviter chaque fois d'aller rechercher dans d'anciennes initGUI() les pavés, ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// place JMenuBar dans un JDialog visuelPages en utilisant une instance //d'une classe abstraite obtenu via une méthode static getMenu(...) qui //prend en paramètre un tableau d'Objets JMenus, classe avec laquelle //j'obtiens un JMenu nommé jmMiseEnPage, contenant autant de //JMenuItems que je voudrais en mettre dans le tableau de chaînes, ici //un seul JMI pour un seul JM, c'est un essai ... visuelPages.setJMenuBar(AbstractMenu.getMenus( new Object [] { new JMenus("name=jmMiseEnPage,text=mise en page", new String [] {"name=jmiPages, text=Pages"})}

---

un essai, puis avec java 5.0 quand je l'aurai, je zapperai le tableau d'objet pour getMenus(JMenus...menus){...} avec l'ellipse, que je lisais cet aprem dans une fac.
je viens de trouver un truc trés interessant donné par [white_rabbit] dans un autre post, sur un site excellent, javaalmanac.com, je crois que de toute façon je vais faire appel à une classe de reflexion pour pas entrer en dur les if(prop.equals("name")) this.setName(value);pour toutes les propriétés mais je vois avec l'interface BeanInfo un autre moyen d'appréhender le problème, car :

Code:

---

1 2 3 4 5 6 7 8

PropertyDescriptor [] pds = null; MethodDescriptor [] mds = null; try{ BeanInfo bi = Introspector.getBeanInfo(JMenu.class); pds = bi.getPropertyDescriptors(); // donne les propriétés, ex : "name" mds = bi.getMethodDescriptors(); // et les méthodes, ex : "setName" }catch(IntrospectionException IE){}

---

reste à apprendre à manipuler tous çà ...
A+
ps : http://javaalmanac.com/egs/java.beans/GetProps.html?l=rel

ok merci bouye, c'est plus clair, je vais le passer en résolu.
A+