Discussion :

[Invité]

Bonjour,

J'utilise Spring MVC et possède beuacoups de beans maisons affichés dans mes formulaires. Pour éviter d'écrire un Editor pour chaque bean, je cherche à réaliser un editeur générique.
Je usi dans une application orienté donnée dans laquelle se trouvent des 'Managers' qui me permettent des acces CRUD sur mes beans. (Se sont en réalité des facades (design pattern) pour utiliser mes daos).

Une solution serait de créer un "bête" editor qui reçoit le manager approprié et qui utilise ce manager pour récupérer un bean par son id. Mais la généricité m'oblige à utiliser Object comme type de retour et je n'aime pas beaucoup ça. Il existe peut-être un méthode plus propre, encore pus générique..

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
 
public interface IdBeanManager {
   // Je me retrouve avec un type de retour très large, je n'aime pas bcp ça.
  public Object getObject(int id);
}
 
public class MonBeanManager implements IdBeanManager {
   private MonBeanDao dao;
   ...
   public Object getObject(int id) {
     return dao.getBean(id);
   }
}
 
public class GenericPropertyEditor extends PropertyEditor {
  private IdBeanManager manager;
  ...
  public Object getAstText(String text) {
    try {
      return manager.getObject(Integer.parseInt(text));
    } catch (...) { .. }
  }
}

Je suppose ne pas être le seul à avoir ce besoin, je fais donc appel à votre expérience.

Merci et bonne année

[novayl]

Tu as pensé à utiliser la covariance de java 5 ?


La FAQ Java :

3) La covariance du type de retour (Java 5.0) :
La version 5.0 de Java apporte une nouvelle possibilité : on peut
désormais modifier le type de retour de la méthode. Toutefois, il faut
que le nouveau type hérite du type de retour d'origine afin de ne pas
rompre le contrat. Ainsi, notre méthode pourrait retourner un
Long (puisque Long hérite de Number) :
Changement du type de retour :


protected Long getValue(int value) throws IOException;

Au final, on peut obtenir des méthodes très différentes alors qu'elles
redéfinnissent bien la même méthode :
Quelques exemples :


public Double getValue(int value);

protected Long getValue(int value) throws FileNotFoundException, ZipException;

etc...


Attention, les changements de signature affecteront bien sûr les classes
filles...

De plus, il peut devenir difficile de voir qu'une méthode en redéfini
une autre avec tant de modifications. Dans ce cas il est fortement conseillé
d'utiliser l'annotation @Override de Java 5.0 (si possible)...

Le lien vers un article de notre site adoré : http://sznajderman.developpez.com/ar...va/covariance/

[Invité]

Oui bien sur mais ça m'oblige quand même à créer autant de classe que j'ai de beans susceptibles d'êtres présentés dans une page. Et je veux eviter cela.

Mais ta réponse m'a amené à suivre quelques liens de plus en plus intéressant. Je devrais d'ici peu rajouter un petit bout de code utilisant la généricité qui à mon avis devrais solutionner mon problème.