Discussion :

[maelstrom]

Bonjour,

J'aurais besoin de savoir comment Update ou refresh un part. J'en ai besoin car j'ai une part qui doit afficher tel ou tel chose selon ce qu'on sélectionne dans une autre. Du coup ma Part se construit de cette façon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	@PostConstruct
	public void createControls(Composite parent)
	{
		if(pickedState.getSelectedObjects() == truc)
		{
 
                 }
                 else
                 {
 
                  }

Et pour l'actualiser actuellement j'ai créer un Handler qui détruit la Part et qui la reconstruit au moment ou je change de chose que je sélectionne, cependant ça ne marche pas très bien, c'est moche, et je suis pratiquement sûr qu'il y a une meilleure façon de faire mais je ne la trouve pas.

Voici mon handler actuel :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
@Execute
	public void execute(EPartService partService, MApplication application, EModelService modelService)
	{
		MPart oldPart = partService.findPart("net.zephyr.graphicInterface.parts.PropertiesPart");
        partService.hidePart(oldPart);
		// create new part
		MPart newpart = oldPart;
		// get the part stack and show created part
		List<MPartStack> stacks = modelService.findElements(application, null, MPartStack.class, null);
		stacks.get(3).getChildren().add(newpart);
		partService.showPart(newpart, PartState.VISIBLE);	
	}

Peut-être que ma façon de penser est erroné dès le départ, si vous avez une meilleure solution faites en moi part

[joel.drigo]

Salut,

Oui, c'est sûr recréer le "part" est une mauvaise solution. Au pire, recréer le contenu du Composite parent passé en paramètre de createControls :

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
 
/* ... */
private Composite content;
 
 
public void createControls(Composite parent)
	{
           content = new Composite(parent, SWT.NONE);
           content.setLayoutData( GridDataFactory... );
           content.setLayout( GridLayoutFactory... );
           fillContent();
 
}
 
/* ... */
 
protected void refresh() {
     removeContent(); // dispose les widgets mis dans content
     fillContent();
}
 
/* ... */

Maintenant, il faudrait savoir exactement :

• le contenu du part (si c'est un StructuredViewer, on peut appeler setInput() pour faire la mise à jour de l'affichage par exemple) ;
• Sur quel évenement la mise à jour doit s'effectuer (en général sur changement de sélection, mais ça peut être autre chose) ;
• quel type de Part ? Vue, Editeur ?

[maelstrom]

En gros c'est une Part qui va afficher des Label, Text et TableViewer différents selon l'objet sélectionné. Je construit mes Part avec windowBuilder et j'utilise des objets SWT. Comme le nombre et l'emplacement diffère selon l'objet sélectionné, j'avais pensé à mettre sa dans un if et de construire la Part selon l'objet sélectionné. Cependant comme je l'ai dit ça ne marche qu'une fois.

L’événement se gère au changement de sélection, quand la sélection change j'appelle le Handler.

Mon composite est comme cela pour l'instant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
@PostConstruct
	public void createControls(Composite parent)
	{
		ScrolledComposite scrolledComposite = new ScrolledComposite(parent, SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
		scrolledComposite.setLocation(149, 0);
		scrolledComposite.setExpandHorizontal(true);
		scrolledComposite.setExpandVertical(true);
 
		Composite composite = new Composite(scrolledComposite, SWT.NONE);
		composite.setLayout(new GridLayout(8, false));
         }

[joel.drigo]

Déjà, pour la réaction au changement de sélection, tu peux simplement enregistrer un écouteur sur le changement de sélection sur le viewSite de la vue.

Ensuite, tu parles de créer des composants différents en fonction de la sélection, ça me semble pas très compatible avec windowbuilder, qui sert plutôt à faire des interfaces statiques. Ou alors tu as un nombre fini et limité de formulaires très différent (construire des formulaires dynamiquement est plutôt simple).

Mais peu importe, fais une série de classes qui étendent Composite, une par type de formulaire. Pour créer un formulaire il suffit d'instancier l'un de ces Composites et pour le détruire d'appeler dispose() sur cette instance.
Autre solution, si l'impact mémoire n'est pas génant, créer tous les Composites possibles, les mettre dans un StackLayout, et sélectionner le bon au changement de sélection.

Le remplissage des données se faisant à part évidemment.

[maelstrom]

Des formulaires différents je risque d'en avoir 15-20 peut-être plus donc la dernière solution me semble un peu trop rude pour la mémoire.

Après l'exemple de code que je t'ai mis c'était le début de ma Part le tronc commun à tous mes formulaires avant le if :

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
@PostConstruct
public void createControls(Composite parent)
{
	ScrolledComposite scrolledComposite = new ScrolledComposite(parent, SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
	scrolledComposite.setLocation(149, 0);
	scrolledComposite.setExpandHorizontal(true);
	scrolledComposite.setExpandVertical(true);
 
	Composite composite = new Composite(scrolledComposite, SWT.NONE);
	composite.setLayout(new GridLayout(8, false));
 
        if(pickedState.getSelectedObjects() == truc)
	{
                Label lblIndex = new Label(composite, SWT.NONE);
		lblIndex.setText("Index :");
 
		textIndex = new Text(composite, SWT.BORDER);
		textIndex.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 1, 1));
         }
         else
         {
                Label lblLength = new Label(composite, SWT.NONE);
		lblLength.setText("Length (m) :");
 
		textLength = new Text(composite, SWT.BORDER);
		textLength.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 1, 1));
         }
}

(C'est un exemple il y a évidemment beaucoup plus de paramètre et d'objet différent).

Le problème n'est pas à gérer le changement de sélection ça je le gère déjà.

J'ai une question par rapport au formulaire dynamique, ça à l'air très bien, mais peut-on gérer 10-15 formulaires radicalement différents avec cela ?
Deuxièmement Avec l'exemple de code que je t'ai montré penses-tu que la solution de créer une classe qui étendent Composite, une par type de formulaire est toujours une bonne solution ? Car je vois bien comment désafficher avec cette solution grâce au dispose(), mais je ne vois pas comment ré afficher le bon formulaire (faut-il créer une fonction pour chaque formulaire qui instancie le bon Composite ?)

[joel.drigo]

Les classes qui étendent Composite (une par type de formulaire donc), peuvent être bien étendre une abstraction qui étend composite et qui représente le formulaire type. Pour la sélection de la bonne classe de composite, tu peux procéder par adaptation, ce qui permet en plus au part d'être indépendant des objets sources de données, et surtout de s'occuper du code du formulaire dans une classe isolée du reste, ce qui simplifie le boulot.

L'abstraction aura juste trois méthodes, au moins (Si tu as besoin de gérer des actions (de vue), il te faudra éventuellement d'autres méthodes pour s'interfacer avec l'implémentation concrète) :

• une pour créer les controls en passant le bon parent
• une pour détruire le composant
• une pour injecter les données (à la manière de setInput de Viewer)

Après, la question est de savoir si les formulaires sont complètement différents ou partiellement différents. Dans le second cas, tu peux simplement avoir des méthodes utilitaires qui construisent des parties du formulaire (par exemple une méthode qui construit une section avec un TableViewer). Ensuite, chaque implémentation de l'abstraction fait appel (ou pas) à ces méthodes, ce qui permet de construire un formulaire spécifique.

[maelstrom]

Aurais-tu un lien de tutoriel et/ou exemple pour ce concept d'adapter car c'est un peu trouble pour moi là. Je ne l'ai pas précisé mais mon projet un est Eclipse 4 Application Project (je ne sais pas si ça change quelque chose, mais je préfère le préciser au cas où).

Mes formulaire sont vraiment différents, déjà tous les objets sélectionnables n'ont pas le même nombre d'attribut, ensuite les attributs n'ont pas le même type, du coup je construis et j'adapte la Part pour chacun des formulaires avec windowBuilder.

[joel.drigo]

Le principe de l'adaptation est de dire faire correspondre à des instances de certaines classes, d'autres instances d'autres classes. Par exemple, j'ai une API qui manipule des instances de classe A, et je veux pouvoir manipuler une instance de classe B avec cette API : je vais donc créer une instance de A qui représente l'instance de classe B.

Dans ton cas, tu as un objet qui représente un formulaire, mettons qu'on l'appelle AbstractViewer, une classe de base qui étend Composite, destinée à contenir un formulaire. Tu as différents objets de classe X, Y et Z, par exemple. Pour chacune de ces classes, on va faire une implémentation concrète de AbstractView, propre à chaque classe X, Y ou Z, de manière indépendante (quand on fait le code du formulaire de la classe X, on ignore complètement ce qu'on a faire pour Y, on peut même ignorer que Y existe.

Donc :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public abstract class AbstractViewer extends Composite {
      public AbstractViewer(Composite parent) {
           super(parent, SWT.NONE);
           createControls(this);
      }
 
      protected abstract void createControls(Composite parent);
 
      /*...*/
 
}

On peut rendre un objet adaptable vers un autre en implémentant IAdaptable sur la classe, mais ce que je te propose est de passer par un IAdapterFactory, ce qui permet de ne pas avoir à modifier l'objet qu'on veut adapter.

Mettons qu'on appelle XViewer, la classe qui étend AbstractViewer, et qui représente le formulaire associé à la classe X. Cette classe ne pouvant être construite sans passer au constructeur le composite parent (obligation SWT), on va résoudre simplement ce problème en adaptant sur une fabrique :

Code :

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

1
2
3
4
5
public abstract class AbstractViewerFactory {
 
      public abstract AbstractViewer createViewer(Composite parent);
 
}

Si tu veux tu peux même passer l'objet à afficher :

Code :

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

1
2
3
4
5
public abstract class AbstractViewerFactory<T> {
 
      public abstract AbstractViewer createViewer(Composite parent, T object);
 
}

Tout d'abord on va implémenter donc un fabrique destinée à fabriquer la classe adaptée :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class XViewerAdapterFactory implements IAdapterFactory {
 
        private static final Class[] ADAPTED = new Class[]{ AbstractViewerFactory.class };
 
 
	public Object getAdapter( Object adaptableObject, Class adapterType ) {
	}
 
 
	public Class[] getAdapterList() {
              return ADAPTED;
	}
}

La méthode getAdapter(Object, Class) est simplement chargée de créer l'instance de XViewer. Le paramètre adaptableObject correspond à l'instance de X à adapter. Le paramètre adapterType correspond à la classe dans laquelle on veut adapter (on peut enregistrer une fabrique d'adapter pour plusieurs types, mais on peut en faire une dédiée pour chaque type, ce que je te décris dans mon explication).

Donc, simplement :

Code :

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

1
2
3
4
5
6
7
8
 
public Object getAdapter( Object adaptableObject, Class adapterType ) {
      if ( adaptableObject instanceof X && AbstractViewerFactory.class.equals(adapterType) )  {
                XViewerFactory viewer = new XViewerFactory(...); 
                return viewer;
      }
      return null;
}

avec :

Code :

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

1
2
3
4
5
6
 
public class XViewerFactory extends AbstractViewerFactory<X> {
     public AbstractViewer createrViewer(Composite parent, X object) {
           /* ... */
     }
}

Ensuite, on utilise l'extension org.eclipse.core.runtime.adapters pour configurer l'adaptation (je n'ai pas mis les packages par simplification, mais ils sont bien sûr indispensables) :

Code xml :

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

1
2
3
4
5
6
7
<factory
            adaptableType="X"
            class="XViewerFactory">
         <adapter
               type="AbstractViewerFactory">
         </adapter>
      </factory>

Ensuite, dans ton code, pour la méthode createViewer(), il suffit de faire :

Code :

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

1
2
3
Object object = /*... selection ... */
AbstractViewerFactory factory=(AbstractViewerFactory)Platform.getAdapterManager().loadAdapter(object,AbstractViewerFactory.class);
AbstractViewer viewer = factory.createViewer(parent, object);

Maintenant, il suffit pour chaque classe dont tu veux afficher un formulaire, faire :

• Un viewer (une implémentation concrète de AbstractViewer)
• Une fabrique de viewer (une implémentation concrète de AbstractViewerFactory) ; éventuellement, on peut utiliser peut-être la même fabrique pour plusieurs types d'objets qui s'affichent de manière identique. On peut même faire une classe unique et procéder par reflection.
• Une fabrique d'adapter (qui implémente IAdapterFactory)
• Ajouter un point d'extension pour configurer l'association

Personnellement, dans ce genre de cas, je fais mon propre point d'extension, ce qui me simplifie le boulot en amont (je n'aurais besoin que d'indiquer le nom de la classe d'objet à afficher, et le nom de la classe qui étend AbstractViewer associée).

[maelstrom]

Ok je comprends beaucoup mieux, je vais quand même faire un résumé pour être sûr que j'ai bien compris :

Tout d'abord on crée les deux classes AbstractViewer et AbstractViewerFactory.
Ensuite pour chaque formulaire on va créer un FormulaireViewer, FormulaireViewerFactory, FormulaireViewerAdapterFactory (et c'est dans le FormulaireViewer qu'on place les éléments graphiques).
Pour finir on rajoute le XML dans le point d'extension (pour chaque formulaire).

Après j'ai juste une question l'objet que tu places dans le XViewerFactory (X dans ton exemple), c'est l'objet que je récupère dans mon if avec pickedState.getSelectedObjects() ?

[joel.drigo]

Après j'ai juste une question l'objet que tu places dans le XViewerFactory (X dans ton exemple), c'est l'objet que je récupère dans mon if avec pickedState.getSelectedObjects() ?

Oui.

[maelstrom]

Hmmmm... Petit point qui pourrait s'avérer embêtant, je gère la multi-sélection dans mon application, et je comptais afficher un formulaire différent s'il y avait plusieurs objets sélectionné. Car en fait pickedState.getSelectedObjects() me renvoi une liste d'objet, si celle-ci à une longueur de 1 je regarde le type l'objet et j'affiche le formulaire approprié avec ces caractéristiques, mais s'il y en a plusieurs je regarde les types des objets et selon le résultat j'affiche un autre formulaire. C'est embêtant ou cela se gère de la même manière ? T peut-il être une liste d'objet ?

[joel.drigo]

C'est un formulaire pour chaque élément de la sélection, ou c'est un formulaire unique pour l'ensemble de la sélection ?

Ou peut-être est-ce le TableViewer qui affiche une liste d'informations pour l'ensemble des objets ?

[maelstrom]

C'est un formulaire unique pour l'ensemble de la sélection (permet de modifier certaines données communes pour toute la sélection plutôt que devoir le faire 1 par 1).

[joel.drigo]

Avec toutes les combinaisons sur 15 objets, ça commence à ressembler à du formulaire dynamique.

J'ai l'impression que tu devrais plutôt opter pour du standard, plutôt que du formulaire dédié. Par exemple en utilisant un PropertySheet. En découpant le formulaire en plusieurs parties peut-être. Tu pourrais me faire une maquette du/des formulaires ?

Par adaptation, au lieu d'adapter sur un composant graphique, on peut toujours adapter sur une description, qui permet de savoir ce qu'on doit mettre dynamiquement dans le formulaire (les champs saissables par exemple). On peut également passer par un modèle de description. C'est ce que je fais dans mon application RCP. J'ai une multitude d'objets; que je ne connais même pas car ils sont configurables dans une intégration de l'application : on configure entre autres une liste de propriétés (nom, type, table de valeurs, etc.). Pour chaque type, j'ai un éditeur de base, mais par différents moyens (adaptation, extension personalisée, fabrique de formulaires, etc.), on peut choisir un éditeur spécialisé. La fabrique de formulaire standard crée un formulaire dynamiquement, en parcourant les champs de chaque objet, et en créant le composant éditeur dédié. Si un formulaire est vraiment complètement spécique (par exemple, il existe un objet "Template", dont le formulaire est complètement graphique, en plusieurs phases, pour lequel la fabrique de formulaire créé une wizard adapté en EditorPart). Il y'a un mécanisme qui permet de savoir si un objet peut-être édité ou pas au sein d'une multi-sélection ou pas, ou si une propriété peut l'être ou pas. Par exemple, le workflow peut-être modifié en multiselection, mais seulement si tous les objets sélectionnés ont le même workflow, et sont dans la même étape.

[maelstrom]

Bon je vais essayer de te faire un résumé en gros dans ma partie graphique on peut mettre des nœuds, des sections, des feux, des ressources diverses et variées, chacun de ces trucs à des caractéristiques bien spécifiques (la seule chose qu'on retrouve en commun c'est peut-être l'index et le Nom, et encore....), certaines de ces caractéristiques se traduiront par Text d'autre un TableViewer, d'autres des radio boutons, enfin bref tout dépends de se dont j'ai besoin. Ensuite dès que j'ai réunis toutes les caractéristiques d'un élément et que j'ai choisis avec quel type je vais les traduire en graphique, j’imbrique et adapte tout cela pour que ce soit "jolie", mais les utilisateurs peuvent aussi me dire, tient celui serait mieux avant l'autre etc...

Donc voilà ce que ça peut donner avec Section :



ou avec Scenario :



Je n'ai pas encore fait les autres mais je risque d'avoir 15-20 ressources à gérer. En plus de cela si on sélectionne plusieurs Sections je veux un autre formulaire où l'on retrouverait que certaines caractéristiques communes comme Wall, Area, Alpha... (Bien évidemment pas Name et Index car on ne va pas nommer toutes les sections de la même façon).

Je pense vraiment que chaque formulaire est vraiment différent car il répond à des besoins spécifiques bien définis pour chaque ressource.

[joel.drigo]

Je pense vraiment que chaque formulaire est vraiment différent car il répond à des besoins spécifiques bien définis pour chaque ressource.

C'est contradictoire avoir la notion de multi-sélection. Ou alors tu prévois 2 cas : un cas monosélection, par adaptation, et un cas multi, pour les champs en commun, que tu peux faire également par adaptation (en créant une classe qui représente une multisélection).
Je pense que tu dois découper ton formulaire en sections, et déterminer les sections en commun, les sections spécifiques, les sections mixtes... Il faut penser que l'ergonomie d'une application doit être synthétique pour éviter de perdre l'utilisateur : tous les formulaires doivent se ressembler, pour ne pas avoir à chercher à chaque fois où se trouve l'information à éditer.

[maelstrom]

Cette une application qui répond à un besoin très spécifiques, je travaille avec les utilisateurs pour que les formulaires leurs conviennent le mieux, donc je fais ce qu'ils me demandent, ce n'est pas moi qui choisi comment faire les formulaire, je propose quelque chose ils corrigent et j'applique. Il faut aussi savoir que ces formulaires se trouvent dans un onglet assez petit de l'application. Pour te faire une idée l'application ressemble beaucoup à eclipse, explorateur de projet à gauche partie centrale où il y a le code, c'est la partie graphique et les onglets en bas là où dans Eclipse on retrouve la console ou problems et bien moi j'ai le fameux onglet Properties où je met mes formulaires. Formulaires qui doivent se mettre à jour selon la sélection.

Mais du coup il est possible de mettre quand je crée la classe FormulaireViewerFactory et que j'étends AbstractViewerFactory<T>, de remplacer le T par une liste de formulaire ? De cette façon :

Code :

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

1
2
3
4
5
6
7
public class FormulaireViewerFactory extends AbstractViewerFactory<List <Section>>
{
     public AbstractViewer createrViewer(Composite parent, List <Section> object)
     {
           /* ... */
     }
}

Est-ce que cela marcherait ?

[joel.drigo]

Ça dépend ce qu'est Section : ça ne peut pas être un composant graphique (on ne peut le créer qu'avec un parent).

Mais on peut faire un adapteur qui retourne une liste de SectionFactory (fabriques de sous-formulaire). Ou tu peux faire tout simplement des méthodes pour chaque type de section dans une fabrique, et l'implémentation de AbstractViewer est une séquence d'appel de méthodes de cette fabrique (l'adapteur retourne une liste de descripteurs qui permettent de sélectionner les méthodes).

C'est quand même un besoin très spécifique. Il y'a plein de manière de faire, et toutes nécessitent beaucoup de temps pour les décrire. A la base, ce que je t'ai dit, avec à la base un Composite qui contient tout le reste, qu'on créé et qu'on détruit, reste vallable. L'important pour moi, c'est de mettre en place un modèle qui permettre d'avoir une base de contruction d'éléments de formulaire avec gestion du databinding, pour pouvoir faire tous les formulaires et combinaisons de formulaires plus rapidement (sans avoir 250 formulaires (ou plus) à écrire).

[maelstrom]

Bon oublions cette histoire de multi sélection pour le moment, je vais d'abord faire un truc correct pour la simple sélection je verrais pour la multi en temps voulut.

Donc j'ai effectué ce que tu m'as conseillé avec les Adapter et les factory donc voilà ce que ça donne pour le SectionViewerFactory :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class SectionViewerFactory extends AbstractViewerFactory<SectionExtension>
{
	@Override
	public AbstractViewer createViewer(Composite parent, SectionExtension section)
	{
    	        Object object = getPickedState().getSelectedObjects();
    	        AbstractViewerFactory factory=(AbstractViewerFactory)Platform.getAdapterManager().loadAdapter(object, AbstractViewerFactory.class);
    	        AbstractViewer viewer = factory.createViewer(parent, object);
 
    	        return viewer;
	}
}

J'ai une erreur sur le loadAdapter "The method loadAdapter(Object, String) in the type IAdapterManager is not applicable for the arguments (Object, Class<AbstractViewerFactory>)". J'ai essayé de changer la variable object par la variable section et j'ai le même message "The method loadAdapter(Object, String) in the type IAdapterManager is not applicable for the arguments (SectionExtension, Class<AbstractViewerFactory>)".

Une idée d'où ça provient ?

[joel.drigo]

Le code ci-dessous devrait être dans ton part :

Code :

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

1
2
3
Object object = getPickedState().getSelectedObjects();
    	        AbstractViewerFactory factory=(AbstractViewerFactory)Platform.getAdapterManager().loadAdapter(object, AbstractViewerFactory.class);
    	        AbstractViewer viewer = factory.createViewer(parent, object);

Dans la fabrique d'adapteur, on doit juste construire un AbstractViewerFactory, et dans AbstractViewerFactory, un AbstractViewer, qui est un Composite.