Bonjour tout le monde.
On m'a demandé de realiser une appli en utilisant GEF (Imposé).
Bien evidement, je ne connaissait que tres peu le java, encore moins eclipse et absolument pas GEF...
Bref, je commence serieusement a deseperer vue la vitesse a laquelle j'avance...
 
Aujourdhui voila ou j'en suis :
- j'ai pris en main eclipse
- j'ai créé un plugin RCP
- j'ai geré tous les probleme de dependance GEF/Draw2D
- j'ai créé mon modele (simple)
- j'ai mon graphical viewer
- j'ai mes editpart (avec la factory)
- j'ai mes figures
- et je sais transmettre les modifications du modele a l'editpart associé pour mettre a jours la vue.
 
(j'ai quand meme mis pas loin d'un mois...)
 
les documentations trouvées sur le net sont rares, incompletes et surtout sur-developpent l'aspect "conceptualisation" et laissent de coter l'aspect pratique "codage" d'autant plus qu'on ne trouve presque aucun exemple. Du coup j'avance a deux a l'heure..
C'est la 1ere fois que j'ai autant de difficulté a avancer et je me dis que j'y arriverai pas.
J'ai vraiment l'impression que ce truc a été fait par des autistes pour des autistes.
 
 
Bref, maintenant que j'ai poussé mon coup de gueule, j'en viens aux faits :
J'essais deseperement de catcher les events du clavier/souris sur ma view pour la faire remonter a l'editpart concerné afin que celui ci update mon modele. Par la meme occasion, comprendre comment est géré (de maniere "ligne de code" ) l'undo/redo et le drag&drop.
 
Si quelqu'un qui c'est deja arraché les cheveux sur ce probleme passe par la, je lui en serait eternellement reconnaissant s'il pouvait m'aider.
 
Je peux fournir les sources de mon petit projet de test si besoin est.
 
 
Allez hop, j'y retourne  

Allez hop au boulot ! Et envoie ici ton source qu'on regarde "ce qui manque" dans ta recette.

J'ai fait au plus simple : http://psykokwak.serveftp.com/vrac/TestGEF.zip

GEF c'est G**** Eclipse Framework ?

c'est "Graphical Editing Framework" bien que c'est pas le nom que je lui aurait donné  

pour le undo je sais pas comment c'est géré dans SWT, mais dans SWING y'a une API pour ça
 
http://java.sun.com/docs/books/tut [...] tener.html
 
tu peux voir si il existe un équivalent...

Pas d'autistes dans le coin ?  

attire-les : lance des cure-dents par terre, et demande qui joue en premièr e base...

http://www.eclipse.org/articles/Ar [...] F-dnd.html
 
T'as regardé ça ?

Oui oui, j'ai vu cet article.
Mais je dois avouer qu'il me manque des briques autour pour comprendre ou et comment intégrer les bouts de code.
Et l'exemple complet donné ne concerne que SWT

salut psyjc !!
tu trouvera ds ce site ce que tu recherche mais c'est en japonnais
il faudrai que tu le traduise à partir d'un site de traduction :
http://www13.plala.or.jp/observe/GEF/
site de traduction:
http://babelfish.altavista.com/
bonne nage.

Merci slimBBA.
Je vais voir ca ..........
On touche le fond  

C'est encore moi.
Je tenais a remercie slimBBA pour son tuto en japonais. C'est le plus clair de tous malgres la langue...
J'en profite pour dire que j'ai commencé a écrire un tutorial en français sur GEF qui permettra a ceux comme moi, d'acquérir les bases. La rédaction prends du temps alors les parties viendront au fur et a mesure.
J'espère qu'il sera utile.
 
Le voici : http://www.psykokwak.com/blog/index.php/tag/gef

 
Mes condoléances
 
Moi aussi on m'a demandé de réaliser une mini-appli en utilisant GEF.
Mais après quelques jours où je n'ai pas du tout avancé d'un poil dans l'appli et où je continuais à galérer à essayer de comprendre GEF, j'ai décidé de laisser tomber GEF et de réaliser l'appli en utilisant awt et swing. Résultat j'ai fait un très bon choix car je m'en suis très bien tiré et j'ai finalisé l'appli dans les délais, ce qui n'aurait pas du tout, mais alors pas du tout été le cas si on m'avait forcé à utiliser GEF.

hehe, J'aurai parfaitement compris ton choix il y a quelques mois quand j'ai posté ce topic.
Mais aujourd'hui je ne regrette pas GEF qui est vraiment une machine super puissante.
Et puis tu n'a plus d'excuses, j'ai rédigé un gros tutorial (le lien deux messages au dessus) pour tout ceux qui ont peur de GEF

J'avais bien vu ton tutorial, et passé du temps dessus, mais malgré cela ça ne m'a pas empêché de galérer avec GEF, puis de laisser tomber.

GEF n'est qu'un exemple, mais je remarque que les décideurs/chefs de projets et développeurs cherchent dans leurs projets à utiliser pleins de technologies et outils tous plus complexes les uns que les autres (frameworks, design patterns, diagrammes de classes tentaculaires et totalement incompréhensibles sauf pour celui qui a fait le diagramme, et autres conneries du genre), juste pour être tendance.  Résultat au lieu de simplifier les développements, je trouve que l'effet produit est inverse, ça rend le code plus complexe, plus opaque, beaucoup plus lourd.
Finalement on se retrouve avec X lignes de code (X énorme) alors qu'en faisant ça avec du bon vieux C on se retrouverait avec facile X/5 lignes de code et cerise sur le gateau un code beaucoup plus optimisé et une appli qui ne rame pas.

Concernant les Design Patterns :
D'accord pour dire que faire du Design Pattern juste pour le dire qu'on en fait ça sert à rien, mais tout dépends du contexte.
Si ton appli est en l'occurence un truc vraiment enorme, c'est mieux d'utiliser les design patterns qui correspondent, c'est à ça qu'ils servent d'ailleurs ...
Après les gens sont libre d'en faire ce qu'ils veulent (malheureusment pas toujours que du bon comme tu le suggère), Mais ça n'est pas qu'un courant de mode.
Bien utilisé, un design pattern permet justement de simplifier et d'améliorer un programme (en tous cas sa conception et implicitement sa réalisation)
ça permet de ne pas avoir à se reposer sans cesse les mêmes questions parce que certains se les sont déjà posées.
C'est un peu comme des "good practices" (bonnes pratiques) de haut niveau ...

N'empêche qu'il y a du vrai. Bcp de vrai même.

L'usage des serveurs d'appli usines à gaz à tout bout de champs par exemple, je n'ai jamais vraiment compris leur intérêt.

Quand on fait une appli destinée à être déployée sur un serveur d'appli, il faut bien sûr qu'elle soit compatible avec Tomcat/JBoss/Websphere/Weblogic et je ne sais quoi d'autre. Du coup, on est obligé d'embarquer dans un war 15000 jar qui sont bien sûr incompatibles avec les divers serveurs d'appli sauf horribles bidouilles dans les classloaders. Parfois, on peut se retrouver avec N jars dont on n'a pas la moindre idée de ce qu'ils font ni même comment ils sont arrivés là, et c'est le début des emmerdes.

Perso, j'aime bien savoir exactement à quoi sert chacun des jars que j'embarque, et au final, une fois qu'on a fait le tri, dans les 3/4 des applis, un petit nombre d'entre eux sont réellement indispensables.
D'expérience, pour un appli de gestion basée web sur un serveur d'appli, qui va fournir les services habituels comme le démarrage, le logging, le XML et les webservices, je peux faire une appli de gestion de n'importe quelle taille avec:
- un Hibernate ou un iBatis (1 seul petit jar pour ce dernier, et surtout pas de dépendances)
- un framework IoC style Spring ou Guice
- une couche présentation (Stripes par ex) avec éventuellement un peu de décoration
Dans quelques besoins particuliers, j'ai eu à utiliser une lib Apache Commons ou xstream (pour faciliter le sérialisation/désérialisation XML). Pour l'application temps réel de règles de gestions, une base de données embarquée style H2, un moteur de règles style JBoss Rules ou un event processor style streamcruncher peuvent s'avérer utiles.
Quasiment tout le reste est superflu. C'est suffisamment bloaté comme ça pour qu'on aille s'encombrer de dizaines d'API supplémentaires.