Meilleure approche d'action à deux états

Question

J'ai récemment mis en place un Action qui permet de basculer l'état activé d'une fonction d'affaires. Chaque fois que l'utilisateur appelle l'action que je mets un drapeau booléen: « willEnable » pour déterminer si l'invocation suivante activer ou désactiver la fonction. De même mettre à jour le nom de l'action, une courte description et icône pour refléter le nouvel état. Ensuite, au sein de ma méthode de actionPerformed(...) je prends une autre action en fonction de l'état de willEnable.

1. Est-ce l'approche ou lorsqu'il peut quelqu'un recommande un meilleur (comme je ce suspect est un problème commun)? (Je peux voir que les actes de JToggleButton comme un bouton à deux états mais je veux cette action soit visible sur un JMenuBar ainsi qu'un JButton, il ne pense pas que ce soit appropriée).

EDIT

Plus précisément, comment les applications comme beaucoup d'IDEA avec cela? Seraient-ils utiliser des actions multi-états (comme ci-dessus) ou seraient-ils échanger un différent Action dans un JButton donné en utilisant setAction(Action)? Peut-être que cette approche est mieux?

2. Lorsque la mise à jour des propriétés de une action puis-je compter sur des composants de l'interface graphique initialisée avec ce Action (par exemple, JButton) automatiquement repeindre se? Que faire si le JButton les changements de taille en conséquence? Devrais-je être revalider les contenant moi-même JPanel?
3. Est-ce changer le nom de l'action une mauvaise chose à faire? Ceci est la seule façon peut faire le changement de texte JButton, mais je suis consciente que le nom devrait probablement rester constante si l'action est placée dans un ActionMap.

Merci d'avance.

Answer 1

J'attendre à ce que l'un des composants de l'interface graphique qui est créé avec des données « modèle » (je comprendrait un Action comme un modèle de données) doit se faire enregistrer en tant qu'auditeur à ce modèle. Il doit prennent des mesures appropriées, erm, action sur un PropertyChangeEvent de feu:. Tout autre comportement constituerait un bug à mon avis

La chose douteuse est ici s'il est légitime de changer le nom de l'action; Je pense que il est pas légitime . Votre action est logiquement ToggleEnabledStatus et cela ne change pas parce que l'action a été invoquée. Tout composant qui a besoin d'afficher un autre texte doit se faire enregistrer en tant qu'auditeur au Action puis vérifiez le drapeau de votre willEnable de prendre le cas échéant, erm, action.

Alternativement, vous pouvez écrire votre propre classe qui a mis en œuvre ToggleButtonModel et Action en même temps et contrôlé les événements de changement de l'intérieur. Ceci est beaucoup de code, mais, pour ce peu d'avantages

Answer 2

Vous pouvez regarder les Motif .

Fondamentalement, vous créez une interface et deux (ou plus) les mises en œuvre de celui-ci pour chaque état. A titre d'exemple simple, l'état de désactivation pourrait juste implémenter l'interface de ne rien faire alors que l'état activé fait certaines actions. Pour changer tout simplement vous faire état

interface IState {
  void doAction();
  boolean isEnabled();
}

class EnabledState implement IState {
  void doAction() {
    setState(new DisabledState());
    // do something
  }
  boolean isEnabled() {return true;}
}

class DisabledState implement IState {
  void doAction() {
    setState(new EnabledState());
    // do nothing
  }
  boolean isEnabled() {return false;}
}

private IState state = new DisabledState(); // default is disabled
private PropertyChangeSupport support = new PropertyChangeSupport(this);

void setState(IState state) {
  if (this.state != state) {
    IState oldState = this.state;
    this.state = state;
    support.firePropertyChange("enabled", oldState.isEnabled(), state.isEnabled());
  }
}

void doAction() {
  state.doAction();
}

Bien qu'il soit un peu de frais généraux pour une seule méthode, il paie certainement dès que vous avez plusieurs méthodes qui changent son comportement en fonction d'un seul état.