Discussion :

[Alec6]

Je developpe une collection de composants graphiques qui se veulent complètement indépendants et plugable.

Je suis ennuyé au niveau du I18N car je voudrais que mes composants possèdent leurs bundle dans leur packaging, mais pas forcément le mécanisme d'accès à leurs bundle. Ceci pour des raisons de souplesse et évolutivité.

Je sais pas trop comment m'y prendre pour etre souple.

Des avis ?

[bouye]

J'ai peur qu'il n'y ai pas de bonne solution pour ce cas-là. Du moins j'en ai pas encore trouvée.

Dans mon projet pour le boulot j'ai fait des classes centralisées pour la récupération des données localisée à partir des bundle (texte bien sur, mais aussi icone*, image, curseur, sons, aide en ligne, ...) ainsi que le formattage des messages composés. Idem pour certaines ops de base (dérivation d'icônes à partir d'icones de taille différente, traitements sur des images (plus lumineuses, grisatres, ...), "plugage" avec JavaHelp quand cette extension est présente, ... d'autres trucs encore). Bon bref ca ressemble plus à une API maintenant.

Evidement le pb c'est que tous mes composants internationalisables/localisables sont fortements dépendant de ces classes utilitaires et donc sont difficilement distribuables séparement. Donc si je voulais faire des composants séparés car fera un sacré gros bout de code qu'il faudrait packager, recopier ou dupliquer dans chaque composant.

Je crains donc qu'il ne te faille effectivement recopier la partie accès bundle dans chacun des composants et en plus dans le composant lui-même . Si tu la met dans une classe annexe packagée dans le JAR, tu pourras peut-être être amené a avoir un pb genre "conflit de version" comme avec des DLL où une version plus ancienne de la classe a été chargée précédement par un composant et ne convient pas au composant plus récent utilisé. Ou alors il faut mettre chaque composant et ses classes annexes dans un package séparé. Evidement dans tous les cas on se retrouve avec des duplicats de ces code/classe utilitaires un peu partout.

*En effet certaines images peuvent être peu parlantes voir carrement offensantes dans certaines cultures. Les icones et les images font donc bien partie des données localisables.

[Alec6]

je me dis qu'il faut effectivement que les compsants possèdent un mécanisme simple d'accès à leurs bundle.

Je commence à envisager le système d'inversion de dépendance;
Dans mon package la GUI (IHM) appel une classe I18N_Manager pour avoir
le texte, image, formatters etc... de façon transparente.

Je considère I18N_Manager comme un décorateur et/ou adaptateur qui encapsule un objet spécialement conçu pour le travail d'internationnalization et qui étendrait l'interface I18NProvideur.

De cette façon j'imagine qu'un module externe, de niveau applicatif pourrait implémenters des I18N provideurs, qu'il fournirait au I18N_Manager du composant. Et le I18N_Manager pourrait fournir au I18N provideur les bundles.

L'idée générale, bien sur, est de pouvoir détourner le composant de sa propre internationnalisation, pour le customizer, c'est à dire lui fournir de nouveau bundles pour les Locales non encore développer (306 pays je crois).

Qu'en pense tu ?

[bouye]

Ca semble intéressant quoi que je ne crois pas que le pattern soit celui du décorateur.

J'ai fait qq chose d'équivalent mais pour la gestion des erreurs. j'ai une interface ErrorHandler implentée par chacun de mes composants. Chaque composant est son propre ErrorHandler mais on a la possibilité de le configurer manuellement via setErrorHandler (si paramètre null retour au comportement par défaut). En interne, le comportement par défaut de chaque composant est tout simplement de déléguer à une boite dialogue d'erreur (qui implémente aussi ErrorHandler) qui offre la possibilité de 1) voir l'erreur 2) sauvegarder l'erreur dans un fichier texte 3) l'imprimer 4) l'envoyer par courrier (quand JavaMail est présent). Mais en reconfigurant l'ErrorHandler du comp on pourrait faire tout autre chose. Il y a quand même de la duplication de code entre les comps mais elle est minime.

Pour l'i18n au contraire j'avais des appels à des méthodes statiques dans une classe utilitaire centralisée (équivalent de SwingUtilities) qui redirigait elle-même sur un ResourceManager dont on pouvait faire varier la configuration. Mais une gestion de l'i18n semblable a celle des erreurs serait interressante (et le changement serait assez léger et peut englober très facilement mon code pre-existant). Hum dès que je pourrais je verrai ce que je peux faire dans mon code.

Reste le pb de conflit potentiels si plusieurs composants séparés ont des version différentes de I18N_Manager. Je n'ai quère ce pb car de mon côté il n'est de toute facon pas prévu de distribuer les composants séparéments les uns des autres.

[Alec6]

C'est pas grave si il y a des versions différentes de I18N_Manager car elle n'est utilisée que par le composant;

on peut par contrer lui setter des I18N concrete qui implémente un interface I18N abstraite fourni par le composant.

Donc c'est de la responsabilité de l'application d'implémenter correctement les I18N puis de les fournir aux I18N_Manager.

Ce que je dois définir c'est surtout l'encapsulation pour le moment.

Je vais voir ce que je peux faire et je te tiens au courant.

Plus d'explication sur ton herrorHandler m'interresserait. J'ai implémenter des trucs dans le genre aussi (comme tout développeur qui se respecte je pense).

[bouye]

Ca depend car si elles sont dans le meme espace de nommage alors il y aura conflit. Si c'est une classe interne au composant, ou si le composant et ses classes associees sont dans son propre package, alors pas de pb.
Bon apres si l'implementation ne change jamais, pas de pb.

J'aimerai bien savoir plus en detail comment ca se passe lors du chargement/resolution des classes par la JVM. Elle se contente de la 1ere version rencontree sur le CLASSPATH (ca serait logique et probable) ou chaque composant est englobe dans son "espace de classes" bien a lui qui est accede en premier avant d'aller essayer de resoudre la classe sur le reste du CLASSPATH.

Plus d'explication sur ton herrorHandler m'interresserait

Basiquement c'est une simple boite de dialogue avec un champs qui affiche le message passe ou le message localise de l'exception, un bouton more >> pour voir la trace (quand on a une exception. un champ supplementaire s'affiche en bas de la boite de dialogue. Le text du bouton devien less <<), un bouton save, un bouton print et un bouton send (enabled uniquement si JavaMail est present).

Elle implemente ErrorHandler dans le cas ou on doit la manipuler separement ou en fournir une instance ailleurs (nottement dans le code non-graphique qui utilise aussi cette interface). Les composant eux utilisent des methodes statiques pour provoquer l'affichage de maniere correcte (attacher la boite de dialogue a la fenetre courante par exemple).

En simplifiant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public interface ErrorHandler {
  /** Handle the error.
   * <BR>Might be displaying a dialog box to the user, printing the stack trace or doing nothing.
   * @param t The throwable.
   */
  public void handleError(Throwable t);
 
  /** Handle the error.
   * <BR>Might be displaying a dialog box to the user, printing the stack trace or doing nothing.
   * @param t The throwable.
   * @param message A message.
   */
  public void handleError(Throwable t, String message);
 
  /** Handle the error.
   * <BR>Might be displaying a dialog box to the user, printing the stack trace or doing nothing.
   * @param message A message.
   */
  public void handleError(String message);
}

Pratiquement tous les composant Swing que j'ai etendus ont une gestion similaire de l'erreur (copier/coller entre les composants) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
  /** {@inheritDoc}
   * @since 2.1
   */
  public final ErrorHandler getErrorHandler() {
    return (ErrorHandler) getClientProperty(ERROR_HANDLER_PROPERTY);
  }
 
  /** {@inheritDoc}
   * @since 2.1
   */
  public final void setErrorHandler(ErrorHandler value) {
    if (value == null) {
      value = this;
    }
    putClientProperty(ERROR_HANDLER_PROPERTY, value);
  }
 
  /** {@inheritDoc}
   * @since 2.1
   */
  public void handleError(Throwable t) {
    ErrorHandler handler = getErrorHandler();
    if ( (handler == null) || (handler == this)) {
      ErrorMessageDialog.showDialog(t, this);
    }
    else {
      handler.handleError(t);
    }
  }
 
  /** {@inheritDoc}
   * @since 2.1
   */
  public void handleError(Throwable t, String message) {
    ErrorHandler handler = getErrorHandler();
    if ( (handler == null) || (handler == this)) {
      ErrorMessageDialog.showDialog(message, t, this);
    }
    else {
      handler.handleError(t, message);
    }
  }
 
  /** {@inheritDoc}
   * @since 2.1
   */
  public void handleError(String message) {
    ErrorHandler handler = getErrorHandler();
    if ( (handler == null) || (handler == this)) {
      ErrorMessageDialog.showDialog(message, this);
    }
    else {
      handler.handleError(message);
    }
  }

Et enfin lors du traitement des evements dans la plupart des listener (declares dans les composants) ou des actions on a un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public void gestionDeLEvemementX(XEvent event) {
  try {
     ...
  }
  catch (Throwable t) {
    handleError(t);
  }
  finally { 
     ...
  }
}