| Accueil de l'archive | Service proposé par Hervé AGNOUX |
From: Bruno Marquié <bmarquie@ifrance.com> To: "Liste Java" <java@u-strasbg.fr> Subject: Compositon visuelle VA Date sent: Wed, 20 Dec 2000 12:46:40 +0100 Send reply to: java@u-strasbg.fr Bonjour à tous Dans le cadre d'un projet, on doit developper une application en SWing. On utilise VisualAge. J'ai déjà travailler (un tout petit peu) avec la composition visuelle de VA et je trouve le code généré vraiment merdique. Hors je souhaite vraiment séparer la présentation (SWING) des traitements (les patterns seront bien sur utilisés). Y'a t-il une possibilité de controler le code générer par VA : des options à cocher,... Est ce qu'il y en a parmi vous qui on déjà été soumis à ce genre de problématique et quel démarche avez vous suivi? MErci A+ Bruno __________________________________________________________________________ ____ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
From: "Alban Peignier" <alban.peignier@leuville.com> To: <java@u-strasbg.fr> Subject: Re: Compositon visuelle VA Date sent: Wed, 20 Dec 2000 14:10:02 +0100 Send reply to: java@u-strasbg.fr Personnellement, mon RAD visuel s'appelle "mes 10 doigts et Emacs ..." ----- Original Message ----- From: Bruno Marquié <bmarquie@ifrance.com> To: Liste Java <java@u-strasbg.fr> Sent: Wednesday, December 20, 2000 12:46 PM Subject: Compositon visuelle VA > Bonjour à tous > > Dans le cadre d'un projet, on doit developper une application en SWing. > On utilise VisualAge. J'ai déjà travailler (un tout petit peu) avec la > composition visuelle de VA > et je trouve le code généré vraiment merdique. > Hors je souhaite vraiment séparer la présentation (SWING) des > traitements (les patterns seront bien sur utilisés). Y'a t-il une > possibilité de controler le code générer par VA : des options > à cocher,... > Est ce qu'il y en a parmi vous qui on déjà été soumis à ce genre de > problématique et quel démarche avez vous suivi? > > MErci > A+ > Bruno > > > __________________________________________________________________________ __ __ > Vous avez un site perso ? > 2 millions de francs à gagner sur i(france) ! > Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif > >
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <java@u-strasbg.fr> Subject: Re: Compositon visuelle VA Date sent: Wed, 20 Dec 2000 14:45:10 +0100 Organization: Miriad Technologies Send reply to: java@u-strasbg.fr C'est quand même une espèce de constante du débat Java : on trouve toujours d'un côté les adeptes des RAD/AGL divers, qui génèrent peut-être des applications au code très lourd et très inefficace, et de l'autres les partisans de la ligne dure : le JDK, un éditeur (TextPad pour moi), et un outil de make (ant en l'occurence). Il serait tout de même intéressant, dans le but de clarifier la question, de faire deux choses : - un sondage pour savoir qui, en faisant quoi, utilsie quel outil - un débat qui nous permettrait d'avoir des idées plus claires sur les raisons qui poussent les gens à choisir ces outils. Nicolas Delsaux PS : je suis pour ma part partissan de la rusticité avec mon JDK, mon éditeur et mon makefile ! ----- Original Message ----- From: Alban Peignier <alban.peignier@leuville.com> To: <java@u-strasbg.fr> Sent: Wednesday, December 20, 2000 2:10 PM Subject: Re: Compositon visuelle VA > Personnellement, mon RAD visuel s'appelle "mes 10 doigts et Emacs ..." > > ----- Original Message ----- > From: Bruno Marquié <bmarquie@ifrance.com> > To: Liste Java <java@u-strasbg.fr> > Sent: Wednesday, December 20, 2000 12:46 PM > Subject: Compositon visuelle VA > > > > Bonjour à tous > > > > Dans le cadre d'un projet, on doit developper une application en > > SWing. On > > utilise VisualAge. > > J'ai déjà travailler (un tout petit peu) avec la composition visuelle > > de > VA > > et je trouve le code généré vraiment merdique. > > Hors je souhaite vraiment séparer la présentation (SWING) des traitements > > (les patterns seront bien sur utilisés). > > Y'a t-il une possibilité de controler le code générer par VA : des > options > > à cocher,... > > Est ce qu'il y en a parmi vous qui on déjà été soumis à ce genre de > > problématique et quel démarche avez vous suivi? > > > > MErci > > A+ > > Bruno > > > > > > > __________________________________________________________________________ __ > __ > > Vous avez un site perso ? > > 2 millions de francs à gagner sur i(france) ! > > Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif > > > > > >
Date sent: Wed, 20 Dec 2000 15:14:34 +0100 From: wmatter <wmatter@nagora.com> Send reply to: wmatter@nagora.com Organization: Nagora Communication To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA > Il serait tout de même intéressant, dans le but de clarifier la > question, de faire deux choses : > - un sondage pour savoir qui, en faisant quoi, utilsie quel outil > - un débat qui nous permettrait d'avoir des idées plus claires sur les > raisons qui poussent les gens à choisir ces outils. Peut on développer une maquette (pas un proto) d'ihm (appli bureautique?) en quelques heures et au textpad? Peut on développer un projet en dizaines (centaines?) de jours hommes et avec plusieurs intervenants au textpad + compiler? Mes réponses à ces questions m'ont conduit à prendre des rad. Note : JBuilder (par exemple) permet toujours le contrôle du code. willfried Matter
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Wed, 20 Dec 2000 15:24:59 +0100 Subject: Re: Compositon visuelle VA Priority: normal Send reply to: java@u-strasbg.fr Le 20 Dec 00, Alban Peignier a écrit : > Personnellement, mon RAD visuel s'appelle "mes 10 doigts et Emacs ..." > Pour ma part c'est ce que je fais, mais je le déplore. Je trouve parfaitement nul d'avoir à me taper une séance de sauvegarde- compilation-évaluation pour régler la taille d'une bordure ou la couleur d'un panneau... -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
From: SMITH Xavier <Xavier.SMITH@airbus.aeromatra.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Compositon visuelle VA Date sent: Wed, 20 Dec 2000 15:52:15 +0100 Send reply to: java@u-strasbg.fr Je pense qu'il y a un avantage certain à utiliser les IDEs, à la fois pour les protos (on ne code pas ou peu) et pour les projets conséquents. Ce n'est qu'un question d'organisation : - On arrive maintenant à faire des protos sans coder une seule ligne. - On peut ensuite développer des beans (ihm ou non), que l'on place dans la palette de l'IDE, et qu'on manipule ensuite via le module de Design de l'IDE. C'est ce développement des beans qui est souvent négligé, ce qui fait que le code généré est souvent retouché, et devient alors malheureusement "one shot". Cette partie est lourde à mettre en place, car les beans doivent (à mon avis) être des composants légers; il en faut donc un certain nombre, mais c'est le prix à payer pour avoir un ensemble assez maniable. De même, il vaut mieux coder en premier lieu toutes les méthodes propres à l'applicatif qui vont être sollicitées via des comportements d'IHM, la jonction sera faîte ensuite plus facilement depuis les wizzards de l'outil. Reste ensuite le choix de l'outil. Je ne ferais pas de pub. Mais il vaut meux choisir un outil qui possède un wizzard complet (qui génère tout le code , et non uniquement le squelette de la méthode associée à un évènement sur un objet). Maintenant, c'est vrai qu'on retrouve à la fin des "fils" dans tous les coins sur le design des fenêtres, mais on s'en fiche : ce n'est que de l'IHM, donc du "jetable". Pour finir, les IDEs sont des magnifiques plates formes de développement (les assistants en ligne, avec la liste automatique des méthodes possibles par objet, c'est quand même plus sympa que vi...) Cordialement, Xavier ps : personne n'a une idée pour contourner mon problème sur les TextComponents non éditables qui deviennent gris depuis la JRE 1.3 ?
Date sent: Wed, 20 Dec 2000 16:10:57 +0100 From: William Dodé <wilk@flibuste.net> Organization: Informaticien Indépendant To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: java@u-strasbg.fr Nicolas Delsaux a écrit : > > PS : je suis pour ma part partissan de la rusticité avec mon JDK, mon > éditeur et mon makefile ! Idem pour moi, mais je m'arrange toujours pour ne pas avoir besoin d'interface graphique à la noix, quitte à passer plus de temps avec le client pour lui démontrer les avantages (simple = moins de formation = moins de problèmes par la suite = moins cher). Si je n'avais pas le choix j'essaierai de bien dissocier l'interface du reste et je n'hésiterai pas à utiliser deux produits, un rad pour l'interface et un éditeur simple pour le reste. Faut bien penser à un truc c'est qu'une fois l'interface swing très sophistiquée mise au point, le client va demander un client léger html sans plugin, et tout sera à refaire... bye bye -- William Dodé --- Informaticien Indépendant
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <wmatter@nagora.com>, <java@u-strasbg.fr> Subject: Re: Compositon visuelle VA Date sent: Wed, 20 Dec 2000 16:36:22 +0100 Organization: Miriad Technologies Send reply to: java@u-strasbg.fr ----- Original Message ----- From: wmatter <wmatter@nagora.com> To: <java@u-strasbg.fr> Sent: Wednesday, December 20, 2000 3:14 PM Subject: Re: Compositon visuelle VA > Peut on développer une maquette (pas un proto) d'ihm > (appli bureautique?) en quelques heures et au textpad? > Non, évidement, mais ma question était posée dans le but de savoir pourquoi ces outils étaient utilisés, dans le principe. > > Peut on développer un projet en dizaines (centaines?) de jours hommes > et avec plusieurs intervenants au textpad + compiler? > Aucune idée, puisque je n'ai jamais essayé, cependant je pense que Java permet, à travers la définition de composants au sein de packages et de javabeans, d'éviter que, dans un projet, trop de personnes ne travaillent sur la même partie du code et soient donc obligées de travailler sur les mêmes fichiers. Par conséquent, la présence de plusieurs intervenants ne rend pas la présence d'un RAD indispensable. Il s'agit simplement d'un plus pour le confort de la création d'IHM. > > Mes réponses à ces questions m'ont conduit à prendre des rad. > Note : JBuilder (par exemple) permet toujours le contrôle du code. > Tout à fait, tout comme Visual C++ permet le contrôle du code généré pour les MFC, on peut donc facilement intégrer, par exemple, des messages dans la barre de status ! Essayez pour voir, ça ne prend qu'une journée pour intégrer un message ! Plus sérieusement, j'ai tendance à penser que ce genre d'outils ne présente un intérêt que pour la création d'IHM. Dès lors qu'on souhaite écrire du code "moteur d'applications", ce genre d'outil redevient ce qu'il est : un éditeur intégré dans un gestionnaire d'environnement (comme TextPad !). Loin de moi l'idée de dénigrer la création d'IHM mais, pour avoir dû intégrer une IHM développée sous JBuilder dans une installation, je peux dire que le nombre de classes internes, qui sont d'après "Java Performance" l'une des raisons majeures de la lenteur connue de Java, est tout à fait effarant : chaque panneau génère au minimum une dizaine de classes, là où un codeur n'en mettra qu'une ou deux ! L'un des autres reproches que je fais à ce genre d'outil est qu'il demande sur le PC une puissance tout à fait déraisonable : sur nos PIII 500, les dévloppeurs ont dû passer à 256 Mo de Ram, ce qui est tout de même fabuleux quand on sait que chez moi, je développe avec mes outils rustiques sur K6 200 avec 32 Mo. Par ailleurs, cette puissance a peut-être un coût, que nous ne voyons pas, sur les machines clientes. En effet, si le code est développé sur une machine très puissante, ne risque-t-o pas d'entrer dans la problématique des développeurs de jeux vidéos (qui exigent de leurs clients des machines qui n'existent pas encore pour profiter d'un son 3D avec une image 4D, le tout sur une machine dont la configuration matérielle est peut-être totallement nulle) ? > > willfried Matter > Nicolas Delsaux PS : je joue certainement dans cette discussion le rôle d'avocat du diable, peut-être même avec peu de tact, mais le débat est à mon avis important et mérite, pour moi tout au moins, une réponse qui ne se résume pas à ça va vite pour faire des maquettes.
Date sent: Wed, 20 Dec 2000 19:48:27 +0000 From: Bruno Conductier <bruno.conductier@wanadoo.fr> To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: java@u-strasbg.fr C'est pas de la ligne dur, cela ressemble plus a du masochisme pour la configuration evoquee, textpad :o) Dans ce genre de configuration j'ai utilise pendant plusieurs annees jikes, gmake, cvs et xemacs et ne m'en porte pas plus mal. Toutefois, il est extrement penible de se passer d'un environnement de mise au point digne de ce nom. De meme, on ne peut lutter contre la generation automatique de code a faible valeur ajoutee ou stereotypee (code statique IHM, JavaBeans, voir EJB actuellement). Bruno Nicolas Delsaux wrote: > C'est quand même une espèce de constante du débat Java : on trouve > toujours d'un côté les adeptes des RAD/AGL divers, qui génèrent > peut-être des applications au code très lourd et très inefficace, et de > l'autres les partisans de la ligne dure : le JDK, un éditeur (TextPad > pour moi), et un outil de make (ant en l'occurence).
Date sent: Wed, 20 Dec 2000 20:09:45 +0000 From: Bruno Conductier <bruno.conductier@wanadoo.fr> To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: java@u-strasbg.fr VisualAge ne genere du code qu'en fonction de ton design. Il est clair que plus le design visuel est confus plus l'aspect du code genere sera horrible. Mais pour ce qui de separer la presentation des traitements, on sait faire cela depuis les annees Smalltalk grace au design pattern MVC (cf la fin du mail pour des references adaptees a VisualAge) Premiere remarque, il est parfaitement possible de coder pres du code et de se passer totalement du code qui conduit a des spaghettis visuels. Pour cela, code les parties visuelles statiques en mode visuel. Pour la partie evenementielle tu peux faire reference a tout widget graphique grace aux accesseurs getNomDeComposant() generes par automatiquement par l'outil. La tu reprends le controle total sur la beaute du code ... Si veux utiliser les techniques de programmation visuelle jusqu'au bout, sans faire du jetable pour autant il faut utiliser certaines techniques. Par exemple, ne pas creer un seul gros ecran, mais assembler des sous-composants en utilisant les notions de variables qui te permettent d'abstraire et masquer la complexite des sous-composants. Ensuite, eviter de vouloir creer la totalite de la dynamique avec des connexions visuelles. Enfin, eviter de camoufler le codee manuel au sein du code genere, meme s'il y a des zones prevues pour ce sera un cauchemard pour la maintenance. Il existe de nombreux tutoriaux et articles traitant de ces problemes. Un bouquin extremement interessant est sur le point de sortir "effective VisualAge" http://www.javadude.com/evaj/ Deux extraits de ce livre sont en ligne et devraient t'interesser. Ils traitent de la mise en oeuvre du design pattern MVC au sein de l'environnement de programmation visuelle de VisualAge : Applying the Model-View-Controller Design Paradigm in VisualAge for Java http://www7.software.ibm.com/vad.nsf/Data/Document2672 Advanced Model-View-Controller Techniques http://www7.software.ibm.com/vad.nsf/Data/Document2329 Bruno Bruno Marquié wrote: > Dans le cadre d'un projet, on doit developper une application en SWing. > On utilise VisualAge. J'ai déjà travailler (un tout petit peu) avec la > composition visuelle de VA et je trouve le code généré vraiment > merdique. Hors je souhaite vraiment séparer la présentation (SWING) des > traitements (les patterns seront bien sur utilisés). Y'a t-il une > possibilité de controler le code générer par VA : des options à > cocher,... Est ce qu'il y en a parmi vous qui on déjà été soumis à ce > genre de problématique et quel démarche avez vous suivi?
To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 21 Dec 2000 09:21:24 +0100 Send reply to: java@u-strasbg.fr SMITH Xavier <Xavier.SMITH@airbus.aeromatra.com> writes: > Maintenant, c'est vrai qu'on retrouve à la fin des "fils" dans tous les > coins sur le design des fenêtres, mais on s'en fiche : ce n'est que de > l'IHM, donc du "jetable". Le problème, c'est aussi de considérer systématiquement l'interface graphique comme un ensemble de classes à compiler, qui font référence à d'autres classes, et le tout forme un gros fouilli où l'interface graphique n'est pas différenciée du modèle de donnée sous-jacent. L'approche prise par Glade, par exemple, un gui-builder pour Gtk, est de générer toute l'UI dans un format structuré, XML en l'occurrence. L'interface est ensuite construite au runtime en fonction des informations contenues dans le fichiers XML. C'est limite "bidouille" en C, par ce qu'il n'y a pas d'introspection pour recréer les liens, mais en Java ce serait une excellente solution. Est-ce qu'un RAD pour Java propose ce genre de solution ? A savoir, un GUI-builder qui génère du XML, et l'interface graphique est construite ensuite par une API associée... ? -- Rodrigo
Date sent: Thu, 21 Dec 2000 11:36:09 +0100 From: Rodolphe Godreul <rodolphe@godreul.com> Send reply to: godreul1@bst.bsf.alcatel.fr To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Il me semble qu il y a deja des discussions avancees en cours pour modifier la serialization des classes SWING vers un format XML. La Javadoc de l'API des classes Swing precise d ailleurs que la serialization est a utiliser avec precaution le format de serialization allant changer. A partir de la, on peut imaginer qu il sera possible de faire plein de choses interessantes comme generer une representaion XML d'une IHM avec un IDE puis de la manipuler, creer a partir du code, d un autre IDE.... > solution. Est-ce qu'un RAD pour Java propose ce genre de solution ? A > savoir, un GUI-builder qui génère du XML, et l'interface graphique est > construite ensuite par une API associée... ? > > -- > Rodrigo
From: Olivier Dedieu <Olivier.Dedieu@inria.fr> Date sent: Thu, 21 Dec 2000 14:23:50 +0100 (MET) To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: Olivier.Dedieu@inria.fr > > PS : je suis pour ma part partissan de la rusticité avec mon JDK, mon > > éditeur et mon makefile ! Pareil (+jikes +cvs +jde). Mais je vais peut etre abandonné Make pour ANT. On en dit bcp de bien: http://pharos.inria.fr/Java/annotations.jsp?url=http%3A%2F%2Fjakarta.apache.org%2Fant%2Findex.html Je ne fais plus de Swing ni d'AWT (encore que meme la avec layout manager comprehensible comme celui de Pnuts, ca allait rapidement). Je ne suis plus que server-side, donc mon GUI-designer c'est DreamWeaver sous Windows (tout le reste étant sous Linux) Le pb des IDE c'est qu'il sont integrés mais pas facilement intégrable. Donc si il manque une fonctionnalité qui pourrait etre facilement géré par un outil externe, c'est pas toujours simple d'intégré cet outil à l'IDE. a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Thu, 21 Dec 2000 16:14:53 +0100 Subject: RE: Compositon visuelle VA Priority: normal Send reply to: java@u-strasbg.fr Le 20 Dec 00, SMITH Xavier a écrit : > > Ce n'est qu'un question d'organisation : > Certainement :))) Moi j'en suis resté à Visual Basic, et je serais curieux de savoir comment les RAD se débrouillent avec la notion de "layout" pour les environnements visuels ? Est-ce qu'on peut choisir son layout, les contraintes associées à chaque composant visuel, est-ce qu'on voit tout se réorganiser comme par miracle sans avoir à écrire une ligne de code ? J'imagine le pied si ça marche avec le GridBag ! Faites moi rêver ! -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <Olivier.Dedieu@inria.fr>, <java@u-strasbg.fr> Subject: Re: Compositon visuelle VA Date sent: Thu, 21 Dec 2000 16:17:48 +0100 Organization: Miriad Technologies Send reply to: java@u-strasbg.fr ----- Original Message ----- From: Olivier Dedieu <Olivier.Dedieu@inria.fr> To: <java@u-strasbg.fr> Sent: Thursday, December 21, 2000 2:23 PM Subject: Re: Compositon visuelle VA > > > Pareil (+jikes +cvs +jde). Mais je vais peut etre abandonné Make pour > ANT. On en dit bcp de bien: > Oui, je sais, j'en ai dit justement beaucoup de bien ! Pour préciser,a ctuellement, j'utilise pleinement les fonctionnalités de make de ANT : je développe tous mes packages dans des sous-répertoires d'une racine Java. Dans cette racine, j'ai écrit deux fichiers de configuration : un build.xml qui contient les définitions d'une série de propriétés qui définissent les opérations à effectuer : compilation, documentation (html et TeX), création d'un fichier Jar et lancement d'une classe spécifique de test. Toutes ces opérations peuvent être activées ou non, et la création d'un fichier Jar entraine par exemple la copie de cette archive dans un repository de fichiers JAR. Par ailleurs, l'un des gros avantages de ce fichier de configuration est la facilité d'édition qu'il apporte. En effet, la syntaxe XML choisie par la fondation Apache est extrèmement claire et permet de définir des tâches très complexes, dont l'enchaînement est totallement déterminitse. Enfin, le fait de disposer d'un outil de make écrit en Java+XML rend le tout incroyable : imaginez un peu la performance de cet outil dans une entreprise intégrant, par exemple des postes sous Win*, Linux et MacOS. Evidement, JBuilder tourne, mais avec quelle incroyable facilité on prend son fichier ANT, qui pour le plus gros fait chez moi 4 Ko, pour le porter d'une machine à l'autre afin de faire des tests multiplateforme. On comprend alors pourquoi Apache l'a développé : tous les développeurs Open Source peuvent compiler, facilement et rapidement, tous les projets Apache, dont le serveur Web, Jakarta,... > > > Je ne fais plus de Swing ni d'AWT (encore que meme la avec layout > manager comprehensible comme celui de Pnuts, ca allait rapidement). Je > ne suis plus que server-side, donc mon GUI-designer c'est DreamWeaver > sous Windows (tout le reste étant sous Linux) > > Le pb des IDE c'est qu'il sont integrés mais pas facilement > intégrable. Donc si il manque une fonctionnalité qui pourrait etre > facilement géré par un outil externe, c'est pas toujours simple > d'intégré cet outil à l'IDE. > Mouaip, c'est aussi ce que j'ai tendance à penser... > > a+ > > --------------------------------------------------------------- > Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) > Web: http://www-sor.inria.fr/~dedieu > JavaChannel: http://www.java-channel.org/ > Pharos team: http://webtools.dyade.fr/pharos/ > --------------------------------------------------------------- > > > > > >
From: SMITH Xavier <Xavier.SMITH@airbus.aeromatra.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Compositon visuelle VA Date sent: Thu, 21 Dec 2000 16:22:03 +0100 Send reply to: java@u-strasbg.fr Yes, you can ! Ce que je fais habituellement : - je reste dans un premier temps en placement "pixel" - j'essaye ensuite de me rapprocher d'une combinaison BorderLayout, GridLayout et GridBagLayout. Des progrès sensibles ont été fait sur ce dernier. -----Message d'origine----- De: Herve AGNOUX [mailto:hagnoux@mail.club-internet.fr] Date: jeudi 21 décembre 2000 16:15 À: java@u-strasbg.fr Objet: RE: Compositon visuelle VA Le 20 Dec 00, SMITH Xavier a écrit : > > Ce n'est qu'un question d'organisation : > Certainement :))) Moi j'en suis resté à Visual Basic, et je serais curieux de savoir comment les RAD se débrouillent avec la notion de "layout" pour les environnements visuels ? Est-ce qu'on peut choisir son layout, les contraintes associées à chaque composant visuel, est-ce qu'on voit tout se réorganiser comme par miracle sans avoir à écrire une ligne de code ? J'imagine le pied si ça marche avec le GridBag ! Faites moi rêver ! -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
Date sent: Thu, 21 Dec 2000 17:06:40 +0100 From: Guillaume Desnoix <guillaume-desnoix@memoire.com> To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: java@u-strasbg.fr Herve AGNOUX: > Est-ce qu'on peut choisir son layout ? Oui > les contraintes associées à chaque composant visuel ? Oui > Est-ce qu'on voit tout se réorganiser comme par miracle sans avoir à > écrire une ligne de code ? Oui > J'imagine le pied si ça marche avec le GridBag ! Justement, ca ne marche pas. Mes essais n'ont jamais ete vraiment concluant. Tout se reorganise, mais souvent n'importe comment. On va aussi vite a tout coder avec 3-4 layouts simples (FlowLO, BorderLO, GridLO) et en n'utilisant surtout pas le GridBagLayout. Guillaume
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Fri, 22 Dec 2000 07:05:25 +0100 Subject: Re: Compositon visuelle VA Copies to: Olivier.Dedieu@inria.fr Priority: normal Send reply to: java@u-strasbg.fr Le 21 Dec 00, Olivier Dedieu a écrit : > > Pareil (+jikes +cvs +jde). Mais je vais peut etre abandonné Make pour > ANT. On en dit bcp de bien: > Je sais plus si j'ai fait une annotation sur le canal java sur ant, mais c'est vrai que depuis la version 1.2 on peut controler de façon eleguante un process de construction d'appli. Pour ma part j'ai pas encore rejeté mes veilles habitudes de makefile, par contre j'utilise ant pour tout ce qui concerne la mise en place des produits à livrer, et je m'en trouve très bien. Pour moi la prochaine étape sera de l'utiliser pour la partie installation. -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
Date sent: Fri, 22 Dec 2000 09:17:30 +0100
From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr>
Subject: Re: Compositon visuelle VA
To: java@u-strasbg.fr
Send reply to: java@u-strasbg.fr
Guillaume Desnoix wrote:
>
> > J'imagine le pied si ça marche avec le GridBag !
> Justement, ca ne marche pas. Mes essais n'ont jamais ete vraiment
> concluant. Tout se reorganise, mais souvent n'importe comment. On va
> aussi vite a tout coder avec 3-4 layouts simples (FlowLO, BorderLO,
> GridLO) et en n'utilisant surtout pas le GridBagLayout.
>
> Guillaume
je pense tu te sers relativement mal du GridBagLayout par ce que c'est
celui qui te donne le plus de liberte dans le placement relatif des
composants, mais par contre c'est l'un des plus contraignant lors du
developpement souvent une ligne avec un GridBagLayout ressemble a ca:
this.add( p__date_panel,
new GridBagConstraints(0, 0, 1, 1,
1.0, 0.0,
GridBagConstraints.CENTER,
GridBagConstraints.HORIZONTAL,
new Insets(0, 0, 0,
0),
0, 0));
Ou this est un panel avec un GridBagLayout, et si tu suis cette regle de
codage tous tes composants se repositionnent parfaitement lors d'un
redimentionnement pour les raisons suivantes: -tu as la maitrise sur le
positionnement dans la cellule (centre, gauche droite etc....) et sur le
nombre de cellules que doit occuper le composant -sur l'elasticite du
composant (dans tous les sens, vertical, horizontal) -sur le poids du
composant, c'est un concept un peu plus dure expliquer en quelques lignes,
mais qui se comprend bien de maniere visuelle(c'est a tester) et
probablement que j'en oublie.....
Donc comme vous pouvez vous en doutez je preche pour le GridBagLayout, ca
demande une bonne comprehention de celui-ci(je m'en sers depuis le
JDK1.0.2), mais apres ca vous donne entiere satisfaction(et quelque soit
la platforme, ce qui est le plus important finalement) Et pour finir (ca
ne va pas plaire a tout le monde) mais un des bon moyens de comprendre
comment marche un GridBag c'est de se servir d'Excel, dans l'idee c'est
pareil.
A+
Philippe.
To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 22 Dec 2000 09:37:44 +0100 Send reply to: java@u-strasbg.fr Philippe Merlaud <philippe.merlaud@natexiscapital.fr> writes: > Donc comme vous pouvez vous en doutez je preche pour le GridBagLayout, > ca demande une bonne comprehention de celui-ci(je m'en sers depuis le > JDK1.0.2), mais apres ca vous donne entiere satisfaction(et quelque soit > la platforme, ce qui est le plus important finalement) Le contre, c'est tout de même qu'il est trop compliqué, trop difficile à relire et à maintenir. J'ai eu cette mauvaise expérience une fois, avec le GridBagLayout utilisé massivement : deux mois après je ne comprenais plus rien à ce que j'avais fait et c'était devenu très compliqué pour faire des modifications. Rien que pour cela, je préfère ne pas l'utiliser, en tout cas à la main. Avec un outil de construction, la question ne se pose plus. -- Rodrigo
Date sent: Fri, 22 Dec 2000 12:31:05 +0100 From: Guillaume Desnoix <guillaume-desnoix@memoire.com> To: java@u-strasbg.fr Subject: Re: Compositon visuelle VA Send reply to: java@u-strasbg.fr Philippe Merlaud: > je pense tu te sers relativement mal du GridBagLayout En fait, pour les raisons expliquess, je ne m'en sers pas ;-) > c'est celui qui te donne le plus de liberte dans le placement relatif > des composants Oui > c'est l'un des plus contraignant lors du developpement Exactement > GridBagLayout ressemble a ca: > this.add( p__date_panel, > new GridBagConstraints(0, 0, 1, 1,1.0, 0.0, > GridBagConstraints.CENTER,GridBagConstraints.HORIZONTAL, > new Insets(0, 0, 0, 0), 0, 0)); Et cela pour chaque composant... donc bcp de code. > tous tes composants se repositionnent parfaitement lors d'un > redimentionnement Avec les autres layouts plus simples aussi. > -tu as la maitrise sur le positionnement dans la cellule (centre, gauche > droite etc....) et sur le nombre de cellules que doit occuper le > composant -sur l'elasticite du composant (dans tous les sens, vertical, > horizontal) -sur le poids du composant, c'est un concept un peu plus > dure expliquer en quelques lignes, mais qui se comprend bien de maniere > visuelle(c'est a tester) et probablement que j'en oublie..... Beaucoup trop de params dont les valeurs peuvent etre incorrectes et que seul un test visuel permet de detecter. D'ou la decouverte tardive de problemes. Alors que ces tests d'IHM ne sont pas necessaires avec les autres layouts. > Donc comme vous pouvez vous en doutez je preche pour le GridBagLayout, > ca demande une bonne comprehention de celui-ci(je m'en sers depuis le > JDK1.0.2), mais apres ca vous donne entiere satisfaction(et quelque soit > la platforme, ce qui est le plus important finalement) J'ai utilise pendant de nombreuses annees l'equivalent (en un peu plus puissant) de GridBagLayout en LeLisp/Aida. Il n'y avait pas le choix. En java, il y a le choix donc je m'en passe. Guillaume