Quelle est l'utilisation prévue de la propriété Nom des composants Swing? Est-ce utilisé swing interne? P>
Contexte: Un collègue a mis en place un mécanisme d'internationalisation en stockant la clé de la chaîne de texte dans la propriété Nom. Ensuite, il parcourt simplement tous les éléments de balançoire et obtient la clé stockée dans la propriété Nom du composant. Il a fait valoir que la propriété de nom ne semble pas être utilisée autrement et que c'était le moyen le plus simple de le faire. p>
3 Réponses :
Nom du composant à partir de Javadoc "Définissez ou obtenez le nom du composant. Ceci peut être utile lorsque vous devez associer du texte avec un composant qui n'indique pas de texte.". Donc, je pense que c'est bien d'utiliser le nom. P>
Vous pouvez également placer quelque chose dans les propriétés du composant. P>
est-il utilisé swing en interne? p> blockQuote>
Réponse courte: oui. p>
Réponse plus longue: plutôt facile à vérifier - construisez simplement de l'interface utilisateur et marchez l'arbre. Ou regarder f.i. swinglabs-démo (ne peut pas résister :-), p>
- Cliquez sur sur la tâche de démonstration jxtree et consultez les noms de certains enfants d'un simple jframe, tel que défini par Swing (illustré dans la parenthèse de Treenode). Li>
- Changez la LAF en Nimbus, cliquez sur la tâche de démonstration jxtre -ble, déplacez la souris sur la barre de défilement du treetable et voyez le nom de boutons de barre de défilement comme défini par la LAF LI> ul>
La question suivante est la suivante: ce réglage interne swing interfère-t-il avec définir le nom des raisons d'application? p>
Réponse courte: difficile à raconter, probablement pas p>
Réponse plus longue: Les paramètres internes que j'ai vus sont peu susceptibles d'être écrasés pour les besoins de l'application car ils sont profondément cachés dans la hiérarchie des conteneurs. En fait, certains cadres comme F.I. SAF utilise le nom de l'injection de ressources (de la même manière que vous décrivez votre collègue. Mon propre cadre de formateurs (non stimulé) a fait des contraintes de mise en page. p>
La définition vague (Lecture: non définie) de la propriété Nom est à la fois un avantage et un piège: p>
- adv: Oui, tout code peut l'utiliser, il n'a pas de contrat réel li>
- Piège: Il existe peut-être de nombreux utilisateurs concurrents de cette propriété LI> ul>
Merci beaucoup pour votre réponse détaillée! Je suppose que je vais simplement le laisser de cette façon, puisqu'il s'agit d'une application assez petite, le risque d'incrimination d'un autre code n'est pas trop gros.
Dans mon expérience, je n'ai jamais rencontré de problème lors de la définition du nom d'un composant pivotant. Pour les composants oscilloires "feuille" (que vous utilisez de manière directe, telle que Comme @kelopatra mentionné, des composants internes des composants oscillants "complexes" (par exemple, selon les utilisations de la propriété code> nom code>, il est souvent utilisé pour l'injection de ressources (I18N), mais il peut également être extrêmement utile pour l'automatisation des interfaces utilisateur (pour les tests ou les démonstrations), car la plupart des robots ( EG Fest Swing) sera en mesure de trouver un composant par nom, à condition que vous attribuiez des noms uniques à vos composants. P> jlabel code>,
jbutton code>,
jmenu code> ...),
nom < / code> est toujours laissé
null code> par balançoire. p>
jcolorchooser code>) peuvent avoir des noms qui leur sont attribués, mais vous ne pouvez généralement pas accéder directement à ces composants internes (autres que de marcher à travers le COPPONENT. Hiérarchie). P>