Discussion :

[dedesite]

Bonsoir tout le monde,
Je me lance dans un gros projet Java et j'ai quelques questions à vous poser.
Tout d'abord, j'aimerais vous parlez un peu de ce projet : il s'agira d'un éditeur d'IHM fait pour les non développeurs. Un programme qui devrait permettre à "monsieur tout le monde" (avec quelques connaissance informatique tout de même) de créer sa propre application, de la faire évoluer etc.
Cela fait plusieurs mois que je cherche la meilleure façon de faire ça, pas techniquement parlant, mais plutôt au niveau de l'utilisation. Je crois avoir trouvé un système qui irai bien et je pense que Java est le meilleur langage pour l'implémenter.

Venons-en à la vrai raison de ce message : mes questions!
Donc, étant donné que le programme que je vais réaliser créera des interfaces (utilisant SWING je pense), il faudra qu'il puisse générer du code Java. Ma question est : connaissez-vous un moyen pratique pour générer du code Java? Une API? Je trifouille pas mal les expressions régulière ces derniers temps et je me suis dis que ça irai bien pour créer un API qui générerai un tel code, mais si quelquechose à déjà été fait je ne m'en priverai pas!!

Autre question, j'utilise le design pattern MVC pour mes interfaces mais comme j'utilise beaucoup d'API externe, mes classes Model on tendance à êre vide. Les API que j'utilise remplace l'utilité du Model. Alors, je me dis que je pourrai faire un générateur d'interface qui n'a que la "view" et le "control", est-ce raisonnable?
Si non, comment en quoi le Model est important?

Merci d'avoir lu ce post, j'èspère qu'une discussion constructive en suivra ,

A+
dede

[eclesia]

...un gros projet en effet.

peut etre peux tu regarder du cote de netbeans, et faire un logiciel basé sur Matisse pour faire tes interfaces.

[benwit]

Bonjour,

Je ne sais pas si ça peut t'intéresser mais j'ai utilsé Jet pour générer du code Java à partir de templates (même langage que les JSP) :
http://www-128.ibm.com/developerwork...ary/os-ecemf2/
http://www.eclipse.org/articles/Arti...tutorial1.html
Certes, Jet fonctionne avec eclipse pour transformer ces templates en classes. Mais une fois les templates figés et les classes générées, plus besoin de Jet. Il suffit de passer les données aux classes-templates et d'enregistrer le code généré dans des fichiers.

Concernant la 2° question, je comprends pas ce que tu entends par "Les API que j'utilise remplace l'utilité du Model". Pour moi, au niveau d'une IHM, la vue, c'est les écrans (Swing ...), le controleur (les actions déclenchées par la vue qui execute des traitements, ...) et le modèle, ce sont les données affichées dans la vue et manipulées par les traitements.
Ceci dit, ayant expérimenté la création d'un framework, il est vrai que lors de la conception de ce dernier, il n'y avait pas grand chose côté modèle, juste quelques interfaces permettant la connexion avec le reste. Et c'est lors de la création d'une vrai application avec le framework que les données viennent : Les classes métiers de l'application.

Sinon et si ce n'est pas trop indiscret, je serai intéressé pour discuter du "système qui irai bien". Après y avoir un peu réfléchi et même si le principe de création d'une IHM par un utilisateur semble sympathique, je reste perplexe.
Bien entendu, et même s'il y a un grand écart entre l'idée et l'implémentation, je comprendrai que tu ne veuilles pas en dire davantage. Néanmoins, n'hésites pas si tu veux obtenir des critiques constructives
La balle est dans ton camps.

[dedesite]

Hum,
merci pour Jet, je vais regarder ça en détail, ça à l'air super performant et comme tu dis, une fois que t'as fait tes template pas besoin de Jet, donc le template peu être appellé d'une application externe si j'ai bien compris?

Ceci dit, ayant expérimenté la création d'un framework, il est vrai que lors de la conception de ce dernier, il n'y avait pas grand chose côté modèle, juste quelques interfaces permettant la connexion avec le reste. Et c'est lors de la création d'une vrai application avec le framework que les données viennent : Les classes métiers de l'application.

C'est de ça dont je veux parlé, du fait que y'a pas grand chose dans mes modèles. Par contre, quand tu parles de tes classes métiers, je crois que mes classes métiers sont situées dans le framework mais c'est du a ma façon de créer l'appli.

Justement, ca fait partis du système que j'ai trouvé pour créer des applications plus modulables et plus intuitives.
Je t'explique (ça ne me gène pas du tout d'exposé mes idées, au contraire) :
En fait, je pense faire un logiciel qui permettera non seulement de créer des applications (une sorte de visual studio mais très très simplifié, donc forcément moins complet) mais aussi de les modifier. L'utilisateur pourra quand il le souhaite lancé le programme de création et modifié lui meme son programme sans être développeur pour un sous.
L'idée c'est de faire des framework "orienté utilisateur" avec une "méta documentation" qui expliquera de manière intelligible le fonctionnement d'une méthode et ce dont elle a besoin pour fonctionner. Bon bien sûr pour que le fonctionnement d'une méthode soit compréhensible, elle doit faire quelquechose de compréhensible et donc c'est pour cela que le framework est constitué d'une part de méthodes "normale" et nécessaire au fonctionnement interne de l'application et d'autre part, de méthodes qui corresponderai au méthodes de la classe métier d'une application, c'est à dire des méthodes appliqué à quelquechose de plus concret et de plus intelligible.
L'éditeur de logiciel serait alors qu'un simple éditeur d'interface et de gestion d'évènement qui appeleront ces fonctions métiers déjà codés.

Donc, ça limiterait certes les possibilités de créations mais au moins ça pourra peut-être permettre a "monsieur toutlemonde" de faire ça propre application, avec l'agenssement et la logique qui lui conviens.
Après, rien ne l'empêchera de rajouter des méthodes au framework pour pouvoir faire plus de choses.

Aussi les logiciels seront plus simple d'utilisation (enfin théoriquement) car l'interface sera "adaptative" c'est a dire qu'elle changera en fonction de ce que fait l'utilisateur. Concrétement, ca se traduit par une gestion des activités utilisateur "par couche".
Par exemple , si un logiciel permet de retouché des photos et de faire du dessin 2D et bah dès le départ on pourra choisir soit de faire du dessin ou soit de retoucher une photo et l'interface sera alors différentes pour les 2 activités et donc moins surchargée.

Vous comprenez le concept??

Merci pour vos réponses, je posterais si j'ai d'autres questions,
Ah ben tiens, il m'en viens une : peu-t-on introduire une fenêtre de rendu 3D généré par un moteur C++ (Ogre par exemple) dans une appli Java???

A+
dede

[benwit]

Concernant JET, le principe, c'est que JET transpose un template style JSP en une classe Java. C'est cette dernière qui prend des paramètres en entrée et qui génére le texte final qu'il faut alors enregistrer dans des fichiers.
Cette classe java peut donc être utilisée à partir de tout autre code java.
Bien entendu, toute modification du template original nécessite une nouvelle transformation par JET : template -> classe Java.
Donc peut être que ça pourra t'aider ou peut être pas ...

Concernant le framework,
Dans mon cas, c'était un framework technique pour faire des applications (interface graphique, persistence, internationalisation, configuration, ...) et donc il n'y avait aucun rapport avec les applications finales. Les applications finales sont basées sur le framework mais concernent un domaine métier (Gestion par exemple). Les vues sont alors les écrans de l'appli de gestion (basées sur des objets graphiques prédéfinies dans le framework). Le controleur, c'est alors les actions déclenchées par l'utilisateur (basées sur des actions prédéfinies (save, create, list, ...)) qui lancent des traitements sur des objets métiers. Les données, c'est alors les objets métiers (Client, Facture, Produit, ...)

Dans ton cas et si j'ai bien compris, ton framework serait un framework ++.
Il intégre à la fois des objets techniques et aussi des objets métiers prédéfinis. L'utilisateur n'a alors plus qu'à relier les objets entre eux et ça marche !!!
Je comprend mieux maintenant le terme de "gros projet". Mais c'est Ennnnnnnnoorrrrrme !!!! Cette approche est très intéressante mais vu le grand nombre de domaines, quels "métiers" penses tu intégrer en premier ? Comment penses tu enrichir ton framework ? par domaine fonctionnel ? par des sortes de plug-ins ? Ou en es-tu dans ton projet ? As tu pensé à te baser sur eclipse par exemple ?

[dedesite]

C'est clair que ça va être énorme!!!

Tout d'abord, merci pour Jet ça à vraiment l'air d'être ce qu'il me faut! Je suis en train de faire le tuto que tu m'as filé là, c'est super puissant comme outils!!

Sinon, pour le framework t'as bien compris ce qu'on pense faire. En fait c'est plus qu'un framework (framework++ j'aime bien lol) c'est un programme à part entière, mais totalement indépendant de l'interface et qui comprend les objets métier.
Pour ce qui est de l'évolution du framework, je n'y ai pas encore trop pensé à vrai dire... Enfin, j'ai bien quelques idées... En fait, je pensais faire un framework par domaine d'activité. Pour faire évoluer le framework, bah je pensais faire ça "normalement", si on veux rajouter une fonction, on la rajoute; si on veux rajouter une classe, on la rajoute, si on veu spécifier un comportement on créer une classe fille...
Il faudra définir des règles comme par exemple un documentation obligatoire enfin du moins sur certain points (je pense même créer des paramètre de documentation spécifique à l'application) .

On compte faire un logiciel de création de jeu vidéo en fait, mais pour l'instant je fais un logiciel de configuration pour ubuntu. Juste un prog qui exectute des commandes linux et qui modifie des fichiers de config. Rien de bien méchant mais c'est cool pour se faire la main.
Pour le "game maker" ça risque d'être plus complexe et j'avoue que je ne sais même pas si ça sera possible de faire ça en Java... Mais après, rien ne m'empêche de générer des interfaces écrites dans un autre langage (C++, Lua ou autre), à moins que Jet soit limité à l'XML, au Java et au JSP...

Le truc c'est que j'y vais un peu a taton vu que je suis pas un spécialiste de ces questions, mais c'est intéressant et j'apprend vite!
Toute aide est la bienvenue .

A+
dede

[benwit]

à moins que Jet soit limité à l'XML, au Java et au JSP...

En fait, les templates peuvent être ce que tu veux comme fichiers sources.
Donc, on pourrait imaginer générer di code C++ par exemple.

Disons qu'après, il faudra compiler les sources générés mais en java, aussi.

[dedesite]

Bonsoir,
J'ai pas mal avancé dans la reflexion sur mon programme et je suis vraiment pas loin de coder quelquechose d'efficace, mais certains problèmes subsistes... Je me dis qu'avec la pratique j'arriverais surement à les régler, mais j'aime bien réflechir aux choses avant de m'y mettre alors pourquoi ne pas vous exposer mes problème avant de mettre les mains dans le combouis?

Tout d'abord, j'aimerais vous expliquez comment je vois mon système d'interface et comment je compte l'implémenter.
Donc, j'aimerais faire des interfaces plus intuitives et plus "logique", concrètement, je me base sur le principe qu'il faut épuré une interface au maximum : ne laissez apparaître que ce dont on a besoin à l'instant T. Une interface pour un logiciel de conception sera donc découpé en étapes et à chaque étape correspondera une interface différente, vous me suivez?
Je trouve qu'un logiciel illustre très bien ce principe ainsi que mes problèmes :
Nero Smart Start!
Je pense que vous connaissez tous ce logiciel de gravure extrêment simple d'utilisation fait pour facilité la gravure qui est à l'origine assez complexe avec Nero Burning Room.
Donc ce logiciel peut se découper en 4 étapes (je fais ça de tête j'en oublis peut-être) :
- Sélection du support que l'on veux graver (CD/DVD, Musique/données...)
- Sélection de ce qu'on veux mettre dans notre CD (recherche dans le disque dur)
- Sélection du dispositif de gravage et des option de gravure (vitesse...)
- Affichage du processus de gravure.

Ces 4 étapes correspondent à 4 interfaces différentes mais certaines parties de ces interfaces sont identiques pour une partie des étapes. Ici, ce sont les boutons "suivant" et "précédent" qui sont présent de l'étape 2 a 4.
On en viens à mon premier problème : comment faire des "étapes" (j'appel ça une activité) différente dans un programme qui partages des composants similaire??
J'ai pour cela trouvé plusieurs solutions en Java :
- Une activité (étape) est un JPanel et il y'a une hiérachie entre ces JPanel (principe d'héritage). Il y'a l'activité de base qui comprend ce qui ne change pas (ici les boutons suivant et précédent) et les autres panel hériterons de celui-ci et auront donc tous les boutons suivant et précédent. Il suffit donc de changer le contentPane de notre frame à chaque fois qu'on veux changer d'activité. Ceci marche bien dans le cas des bouton suivant et précédent car ce sont de simples boutons, mais dans le cas d'un Canvas où ils y'a par exemple des données dessinés, comment faire pour le "passer" à l'autre activité?? Il faut le cloner? Cela ne prendrais pas pleins de mémoire et du temps pour rien? On pourrai les passer en paramètre des constructeur des JPanel hérité?
Dans le cas où j'ai un panel père qui constitu une activité de base et un panel fils qui spécifie cette activité, puis-je passer au constructeur de mon panel fils l'objet qui implémente mon panel père?? Comme ça j'ai exactement le même objet mais avec des possibilités en plus et je n'ai pas bouffé de mémoire vu que c'est le même.


Vous me suivez jusque là ou mes explication sont foireuses???

- Une autre solution consisterait à avoir plusieurs panels indépendants constituant le contentPane, mais ça fait qu'il pourrait y avoir un éventuel conflit entre les différents position des panels (notament avec les layout) et ça enlèverai cette notion de hierachie entre les différentes étape que je trouvais fort sympatique et pratique.
Par contre, le problème des objets qui change quand on change d'activité ne se pose pas vu que tout ne changera pas mais seulement un ou plusieurs des panels constituant le contentPane.

[EDIT] En regardant le site de winDev (j'avais juste entendu parlé mais ça a l'air très puissant comme engin!) je suis tombé sur une vidéo qui illustre exactement ce que j'aimerais faire avec mon logiciel :
http://www.pcsoft.fr/windev/videos.htm

Regardez la vidéo Héritage d'IHM!
[/EDIT]

[EDIT2]
Mais j'hallucine!!! Y'a trop pleins de trucs dans windev 11 que je voulais faire dans mon projet!!! Genre ce qu'ils appellent les actions prédéfinis c'est trop la même idée que le "framework++".
Je suis trop sur le c** de voir qu'une boîte à déjà réalisé un tel programme!
Bon en même temps, je vais tenter de faire quelquechose d'un peu moins technique (encore plus orienté utilisateur) et crossplatforme donc ça sera tout de même différent mais bon, ca fou un coups quand on réfléchis à tout ça depuis plusieurs mois!!!!
[/EDIT2]

Vous suivez toujours où la je vous ai totalement embrouillé?

Bon, quoiqu'il en soit je passe à mon second problème qui concèrne la génération de code avec JET : comment faire une génération de code "dynamique"? Je m'explique : comme je veux faire un logiciel de création d' IHM, il faut que je puisse créer automatiquement les classes des panels qui constituerons mon application (ça c'est pas très compliqué) mais il faut aussi que je puisse rajouter dynamiquement des éléments dans cette classe (des boutons, des listbox etc.) puis faut aussi que je créer des évènements, des fois que j'en enlève etc. Comment faire un template qui prenne tout ça en compte??
Est-il possible de faire plusieurs template qui s'emboite? Genre un template de base pour la création d'un Panel, puis un template pour le rajout d'un panel à l'interieur de ce panel.


Waou!! Ca fait un gros post et complexe en plus!! J'èspère que vous êtes arrivez à tout comprendre et que vous êtes arrivez à la fin sans trop de problèmes!
Si c'est le cas, je serais ravis d'avoir votre opinion sur tout ça!
Quoiqu'il arrive, je vais coder tout le we et essayer d'avoir un système qui tiens la route!

Encore merci à vous, à bientôt,
dede