Simple interrogation sur le développement d'interfaces graphiques :
je suis à la recherche d'un comparatif (quantitatif et qualitatif) sur les
différences de coûts entre la réalisation d'une interface graphique Swing
et d'une interface graphique basée sur le modèle JSP (Struts/Servlet). Le
développement d'une interface Swing semble être près de 5 fois plus rapide
à réaliser, entre le déboggage, le design, le contrôle de session, la
vérification d'enchaînements entre pages... Quelqu'un a-t-il une référence
(comparatifs, statistiques) sur les différences de charges entre les deux
technologies ? Dans le même ordre d'idée, la différence du coût de la
maintenance de telles interfaces graphiques est elle comparable et où
puis-je trouver des références à ce sujet ?

a+

julien

Julien.Piaser@zas.admin.ch wrote:

> Simple interrogation sur le développement d'interfaces graphiques : je
> suis à la recherche d'un comparatif (quantitatif et qualitatif) sur les
> différences de coûts entre la réalisation d'une interface graphique
> Swing et d'une interface graphique basée sur le modèle JSP
> (Struts/Servlet). Le développement d'une interface Swing semble être
> près de 5 fois plus rapide à réaliser, entre le déboggage, le design, le
> contrôle de session, la vérification d'enchaînements entre pages... 

Si tu le dis!! cela me parait carrement surrealiste..
Swing est complexe donc reclame de bons developpeurs pour eviter:
- un code non maintenable
- des perfs minables
- un code jetable

ils doivent maitriser Java, les Design Patterns, se plier aux 
contraintes du deploiement voire anticiper les evolutions de celui ci, ne
pas compter sur des outils puisque le code genere par des outils(du moins
jusqu'a present etait lent et inutilisable).

HTML est simple, bien maitrise par bcp de gens, les outils du marche sont
un vrai plus... donc en passant par un Framework du type Struts tu peux
avoir une interface legere et facilement maintenable a peu de frais..

>Quelqu'un a-t-il une référence
> (comparatifs, statistiques) sur les différences de charges entre les
> deux technologies ? Dans le même ordre d'idée, la différence du coût de
> la maintenance de telles interfaces graphiques est elle comparable et où
> puis-je trouver des références à ce sujet ?
> 

je ne sais pas...

Jerome

> Le
> développement d'une interface Swing semble être près de 5 fois plus
> rapide à réaliser, entre le déboggage, le design, le contrôle de
> session, la vérification d'enchaînements entre pages...

Ca me parait peu réaliste... Ayant déjà travaillé dans des projets de
Swing et de Servlet/JSP, je préfére de loin les Servlet/JSP. Je trouve que
tu peux même te permettre d'avoir une équipe de débutants pour le dev
Internet controllé par un développeur expérimenté.

Par contre, je pense qu'il est rare que tu ais le choix entre Swing et
Servlet/JSP. Ils font parties des architectures différentes. Quel est le
contexte de ton projet?

  Yagiz (http://www.erkans.com)

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Salut

Je n'ai pas de reference mais mon experiene personnelle(2ans de
servlet/jsp..) et celle de mes deux colleges des appli web va dans ton
sens les appli web sont -peu maintenables -peu reutilisable -trop proche
du protocole http

je pense efectivement qu'il existe un facteur
important de cout entre appli web et swing
au moin 3 selon moi

Cela dit de nouvelle solution basé sur les tag librairie/ et struts
www.struts.application-servers.com
www.kobrix.com
devrait reduire ces coûts 
mais je ne suis pas convaincu du resultats
struts est encore assez bas niveau

Pour ma part pour des applications intranet
mon choix est fait Appli/javaplugin/SOAP

Maintenat dans le cas de protail web
le java plugin me parait un peu lourd ;)

A+ marc





>Messsage du 18/02/2002 15:57
>De :  <java@u-strasbg.fr>
>A :  <java@u-strasbg.fr>
>Copie à : 
>Objet : Coût de réalisation JSP/SWING  
>
> Simple interrogation sur le développement d'interfaces graphiques : je
> suis à la recherche d'un comparatif (quantitatif et qualitatif) sur les
> différences de coûts entre la réalisation d'une interface graphique
> Swing et d'une interface graphique basée sur le modèle JSP
> (Struts/Servlet). Le développement d'une interface Swing semble être
> près de 5 fois plus rapide à réaliser, entre le déboggage, le design, le
> contrôle de session, la vérification d'enchaînements entre pages...
> Quelqu'un a-t-il une référence (comparatifs, statistiques) sur les
> différences de charges entre les deux technologies ? Dans le même ordre
> d'idée, la différence du coût de la maintenance de telles interfaces
> graphiques est elle comparable et où puis-je trouver des références à ce
> sujet ?
> 
> a+
> 
> julien
> 
> 

<snip/>

> HTML est simple, 
Sauf que, malheureusement, faire un site web sans Javascript
me parait difficile. Et là, on entre dans le domaine du 
paranormal, avec des version de navigateur à gérer, ...

> bien maitrise par bcp de gens, les outils du marche 
> sont un vrai plus... 

Par rapport à quoi ?

> donc en passant par un Framework du type 
> Struts tu 
> peux avoir une interface legere et facilement maintenable a 
> peu de frais..
> 
> >Quelqu'un a-t-il une référence

Non, mais une préférence oui.

L'investissement est certes beaucoup plus lourd pour
faire une interface graphique avec Swing. Mais quel plaisir
d'avoir dompté le MVC cher à Jérôme (on me dira qu'on peut faire 
du MVC2 avec des servlets, mais bon, pas le même trip...)

En plus, au niveau réutilisabilité, pas photo. Bon, il est vrai
qu'avec des frameworks comme struts ou barracuda, on peut
faire des choses intéressantes, mais je ne crois pas que leur
utilisation soit beaucoup plus simple qu'un éditeur graphique.

Et c'est là que la séparation se fait. Sans vouloir relancer la
polémique séculière, de ton environnement de développement
(s'il t'est imposé) dépendra de la facilité à développer/debugger
ton appli swing ou web (quand même beaucoup plus facile, AMHA, de
débugger du Swing).

Enfin, au niveau du déploiement, HTML avait un réel avantage avant
l'apparition de Java Web Start.

Olivier

> > (comparatifs, statistiques) sur les différences de charges 
> entre les deux
> > technologies ? Dans le même ordre d'idée, la différence du 
> coût de la
> > maintenance de telles interfaces graphiques est elle 
> comparable et où
> > puis-je trouver des références à ce sujet ?
> > 
> 
> je ne sais pas...
> 
> Jerome
> 

je conforte les dires de Jerome par ma propre experience
Swing pour le developpement d'interface est assez lourd a mettre en place
et demande une équipe de développeurs bien formés a la POO.

Il faut prendre en compte le positionnement des composants par layout, la
gestion des evenements par listener et suivre une architecture strictement
MVC (Model et Components) sous peine de se retrouver avec une application
completement ratée......

De plus pour dessiner rapidement des IHM avec un IDE (comme en VB ou en
HTML) c'est la croix et la baniere (ou j'ai raté un IDE génial......)

Et cerise sur le gateau, gérer certaines differences entre les
plate-formes (Win95 qui ne gère pas l'unicode ....)

en conclusion : ne pas confondre Swing et Windev, ca peut faire mal ;-)
___________________________________________________________ Laurent UNAL 


> -----Message d'origine-----
> De:	Jerome Moliere [SMTP:moliere@viveo-montpellier.com]
> Date:	lundi 18 février 2002 16:00
> À:	java@u-strasbg.fr
> Objet:	Re: Coût de réalisation JSP/SWING
> 
> 
> 
> Julien.Piaser@zas.admin.ch wrote:
> 
> > Simple interrogation sur le développement d'interfaces graphiques : je
> > suis à la recherche d'un comparatif (quantitatif et qualitatif) sur
> les
> > différences de coûts entre la réalisation d'une interface graphique
> Swing
> > et d'une interface graphique basée sur le modèle JSP (Struts/Servlet).
> Le
> > développement d'une interface Swing semble être près de 5 fois plus
> rapide
> > à réaliser, entre le déboggage, le design, le contrôle de session, la
> > vérification d'enchaînements entre pages... 
> 
> Si tu le dis!! cela me parait carrement surrealiste..
> Swing est complexe donc reclame de bons developpeurs pour eviter:
> - un code non maintenable
> - des perfs minables
> - un code jetable
> 
> ils doivent maitriser Java, les Design Patterns, se plier aux 
> contraintes du deploiement voire anticiper les evolutions de celui ci,
> ne pas compter sur des outils puisque le code genere par des outils(du
> moins jusqu'a present etait lent et inutilisable).
> 
> HTML est simple, bien maitrise par bcp de gens, les outils du marche
> sont un vrai plus... donc en passant par un Framework du type Struts tu
> peux avoir une interface legere et facilement maintenable a peu de
> frais..
> 
> >Quelqu'un a-t-il une référence
> > (comparatifs, statistiques) sur les différences de charges entre les
> deux
> > technologies ? Dans le même ordre d'idée, la différence du coût de la
> > maintenance de telles interfaces graphiques est elle comparable et où
> > puis-je trouver des références à ce sujet ?
> > 
> 
> je ne sais pas...
> 
> Jerome

Sylvie IRIGOYEN wrote:

>Salut
>
>Je n'ai pas de reference mais mon experiene personnelle(2ans de
>servlet/jsp..) et celle de mes deux colleges des appli web va dans ton
>sens les appli web sont -peu maintenables -peu reutilisable -trop proche
>du protocole http
>
>je pense efectivement qu'il existe un facteur
>important de cout entre appli web et swing
>au moin 3 selon moi
>
>Cela dit de nouvelle solution basé sur les tag librairie/ et struts
>www.struts.application-servers.com
>www.kobrix.com
>devrait reduire ces coûts 
>mais je ne suis pas convaincu du resultats
>struts est encore assez bas niveau
>
Je suis d'accord, c'est plus long. En plus faut trouver
des mecs specialistes de :
  Apache : page statique
  Tomcat : servlet/JSP
  Cocoon : présentation, entree XML, sortie HTML/PDF
  TagLib : Essentiel pour pas alourdir le code JSP
  JBOSS : pour les EJBs, gestion CMP, repartition de charge
  Postgres : pour la BD.

Et ca c'est dur.
Donc c'est plus lourd a mettre en place et surtout a maintenir
que du swing.

>
>
>Pour ma part pour des applications intranet
>mon choix est fait Appli/javaplugin/SOAP
>
pas d'accord pour SOAP, je doit être le seul mec qui
trouve SOAP debile. Ya meme pas moyen d'acceder
a un objet sur le serveur par référence.

Je vois pas en quoi SOAP est une avancé, enfin, je
l'utiliserai comme tous le monde dans deux ans
quand les APIs seront stables :)

>
>
>Maintenat dans le cas de protail web
>le java plugin me parait un peu lourd ;)
>
>A+ marc
>
Remi

>  pas d'accord pour SOAP, je doit être le seul mec qui
>  trouve SOAP debile. Ya meme pas moyen d'acceder
>  a un objet sur le serveur par référence.

Non tu n'est pas seul Remi ! Je suis avec toi. L'idée de XML-RPC etait
bonne mais je trouve que SOAP (heu Microsoft) l'a enormement complexifié.

a+

---------------------------------------------------------------
 Olivier Dedieu
 JALIOS (33) 1 39 63 51 47, fax (33) 1 39 63 52 45
 INRIA Rocquencourt, BP 105, 78153 LE CHESNAY cedex FRANCE
 JavaChannel: http://www.java-channel.org/
---------------------------------------------------------------

Difficile comme question :-)

[Réponse à Yagiz Erkan]

>> Le développement d'une interface Swing semble être près de
>> 5 fois plus rapide à réaliser, entre le déboggage, le design,
>> le contrôle de session, la vérification d'enchaînements
>> entre pages...

> Ca me parait peu réaliste... Ayant déjà travaillé dans des projets de
> Swing et de Servlet/JSP, je préfére de loin les Servlet/JSP.

Je ne serais pas si catégorique :

Si le logiciel est une navigation à travers des données avec une surcouche
d'intelligence, alors Servlet/JSP est une très bonne solution. Quand je
dois développer ce genre de produit sur cédérom en Java j'utilise
JEditorPane pour afficher du HTML :-)

Si maintenant le logiciel est pour exploiter des données fortement
couplées et dont les relations entre elles sont complexes alors une
interface logiciel classique (et donc Swing car AWT ce n'est pas ça :-)
est bien plus adaptée.

> Je trouve que tu peux même te permettre d'avoir une équipe de débutants
> pour le dev Internet controllé par un développeur expérimenté.

Par contre, je suis tout a fait d'accord. On  peut utiliser JSP en ne
connaissant que HTML (avec une supervision) alors que pour Swing il faut
vraiment mettre les mains dans le cambouis et bien connaître Java (voir
même les Thread, :-( )

[Réponse à marc]

> les appli web sont
> -peu maintenables
Pas très vrai quand tu travailles avec Servlet et JSP. Tu arrives a
différentier la couche IHM (Jsp & Servlet) et la couche métier (Servlet &
Java).

> -peu reutilisable
La partie HTML et JSP est jetable mais pas certaines servlet et pas la
couche métier.

> -trop proche du protocole http
Je ne comprend pas trop la remarque.
Veux tu dire que c'est un dialogue asynchrone alors que l'interface
fenêtre classique est pratiquement synchrone ?


> Cela dit de nouvelle solution basé sur les tag librairie/ et struts
> www.struts.application-servers.com www.kobrix.com devrait reduire ces
> coûts

Oui, le modèle MVC est très intéressant et permet une forte réutilisation
des composant d'affichage dans Swing. Vivement une implémentation pour
HTML.

> mais je ne suis pas convaincu du résultats
> struts est encore assez bas niveau

No comment, non testé.
Par contre, j'ai vu l'environnement ASP .NET, il y a de très bonne idées.
On définis sa page de visualisation en HTML et on définit une page de
programmation qui reçoit les évènements. On retrouve à quelque chose prêt
une programmation événementielle que l'on connaît dans les applications
"classiques". Une piste intéressante pour pouvoir faire un modèle MVC.

> Pour ma part pour des applications intranet
> mon choix est fait Appli/javaplugin/SOAP

Tu peux détailler.
La solution .NET (de Microsoft pour ceux qui étaient en vacances sur Mars)
repose aussi sur SOAP (et en plus sur WSDL).

> Maintenat dans le cas de protail web
> le java plugin me parait un peu lourd ;)

Tout dépend de "l'intelligence" du site. Je gère aussi des site HTML+ASP.
Ils sont rapide et peu coûteux jusqu'à un niveau de complexité à partir du
quel un choix plus objet (par exemple Java) devient plus pertinent.


>> HTML est simple, 
> Sauf que, malheureusement, faire un site web sans Javascript 
> me parait difficile. Et là, on entre dans le domaine du 
> paranormal, avec des version de navigateur à gérer, ... 

J'arrive a faire la plupart des sites sans recourir à du JavaScript bien
compliqué (et donc cross-navigateur). Bien sur, il faut accepter une
interface Web et ne pas vouloir des barres de menu, des boîtes de
dialogues, etc... L'ergonomie souhaitée peut faire balancer vers Swing
(l'ergonomie et non la fonctionnalité).


>> bien maitrise par bcp de gens, les outils du marche 
>> sont un vrai plus... 

> Par rapport à quoi ? 

Il n'y a pas d'éditeur aussi simple que DreamWeaver (par exemple, on ne va
pas bataillé sur les éditeur HTML :-) pour faire une interface Swing.

Cordialement,

--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
Tél. 01 41 96 96 76
Fax 01 41 96 96 77
Mél  erik.mazoyer@hyperoffice.fr 

-----Message d'origine-----
De: Yagiz Erkan [mailto:yagiz@erkans.com]
Date: lundi 18 février 2002 16:20
À: java@u-strasbg.fr
Objet: Re: Coût_de_réalisation_JSP/SWING


> Le
> développement d'une interface Swing semble être près de 5 fois plus
> rapide à réaliser, entre le déboggage, le design, le contrôle de
> session, la vérification d'enchaînements entre pages...

Ca me parait peu réaliste... Ayant déjà travaillé dans des projets de
Swing et de Servlet/JSP, je préfére de loin les Servlet/JSP. Je trouve que
tu peux même te permettre d'avoir une équipe de débutants pour le dev
Internet controllé par un développeur expérimenté.

Par contre, je pense qu'il est rare que tu ais le choix entre Swing et
Servlet/JSP. Ils font parties des architectures différentes. Quel est le
contexte de ton projet?

  Yagiz (http://www.erkans.com)

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

L'arrivée de .NET (mais non je ne suis pas pro Microsoft, mais c'est une
nouvelle donnée dans le monde intranet) donne du poids à SOAP.

Je m'intéresse donc à la possibilité d'intégrer Java dans une architecture
.NET.

Avez-vous
- testé,
- lu des articles pour
cette intégration ?

A+

--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
Tél. 01 41 96 96 76
Fax 01 41 96 96 77
Mél  erik.mazoyer@hyperoffice.fr 

-----Message d'origine-----
De: Olivier Dedieu [mailto:olivier.dedieu@inria.fr]
Date: lundi 18 février 2002 17:43
À: java@u-strasbg.fr
Objet: Re: Coût de réalisation JSP/SWING



>  pas d'accord pour SOAP, je doit être le seul mec qui
>  trouve SOAP debile. Ya meme pas moyen d'acceder
>  a un objet sur le serveur par référence.

Non tu n'est pas seul Remi ! Je suis avec toi. L'idée de XML-RPC etait
bonne mais je trouve que SOAP (heu Microsoft) l'a enormement complexifié.

a+

---------------------------------------------------------------
 Olivier Dedieu
 JALIOS (33) 1 39 63 51 47, fax (33) 1 39 63 52 45
 INRIA Rocquencourt, BP 105, 78153 LE CHESNAY cedex FRANCE
 JavaChannel: http://www.java-channel.org/
---------------------------------------------------------------

Remi Forax wrote:

> Sylvie IRIGOYEN wrote:
>
>> Salut
>>
>> Je n'ai pas de reference mais mon experiene personnelle(2ans de 
>> servlet/jsp..) et celle
>> de mes deux colleges des appli web va dans ton sens
>> les appli web sont
>> -peu maintenables
>> -peu reutilisable
>> -trop proche du protocole http
>>
>> je pense efectivement qu'il existe un facteur
>> important de cout entre appli web et swing
>> au moin 3 selon moi 8
>>
>> Cela dit de nouvelle solution basé sur les tag librairie/ et struts
>> www.struts.application-servers.com www.kobrix.com devrait reduire ces
>> coûts mais je ne suis pas convaincu du resultats struts est encore
>> assez bas niveau
>>
> Je suis d'accord, c'est plus long. En plus faut trouver
> des mecs specialistes de :
>  Apache : page statique
>  Tomcat : servlet/JSP
>  Cocoon : présentation, entree XML, sortie HTML/PDF
>  TagLib : Essentiel pour pas alourdir le code JSP
>  JBOSS : pour les EJBs, gestion CMP, repartition de charge
>  Postgres : pour la BD.
>
> Et ca c'est dur.
> Donc c'est plus lourd a mettre en place et surtout a maintenir
> que du swing.
>
>>
>>
>> Pour ma part pour des applications intranet
>> mon choix est fait Appli/javaplugin/SOAP
>>
> pas d'accord pour SOAP, je doit être le seul mec qui
> trouve SOAP debile. Ya meme pas moyen d'acceder
> a un objet sur le serveur par référence.
>
> Je vois pas en quoi SOAP est une avancé, enfin, je
> l'utiliserai comme tous le monde dans deux ans
> quand les APIs seront stables :)
>
>>
>>
>> Maintenat dans le cas de protail web
>> le java plugin me parait un peu lourd ;)
>>
>> A+ marc
>>
> Remi
>
Sisi tu peut passer des référence  avec de holder comme en CORBA !!!
Fou yaya,
SOAP n'est pas une avancée !!!
bon comment te convraincre : (et je pense y arriver ;))
voila en fait c'est sur que si tu te tape APACHE SOAP comme outils ,
je t'accorde que tu va souffrir les martyrs avec une doc à la apache...

Bon tous d'abord si ton objectif est de passer des objet par référence ,
tu te trompes de techno ! Et je suis bien d'accord que RMI et bien plus
adapté, je te conseillerai même CORBA qui va  beaucoup plus vite. -SOAP
c'est une bonne solution quand ton objectif est de passer des appels de
fonctions distants, pas  trop complexes, et dont les performances  ne sont
pas critiques Typiquement pour faire dialoguer des applets avec leur
serveur.

En fait si je pense que pour vous en devrier  jettez un coup d'oeil à la
documentation de GLUE, car je crois que vous avez été refroidi par des
produits ou vous aviez le XML a manipuler pour passer un appel...(et la je
t'accorde que ca apporte rien), avecGLUE tout  le
marshalling/Unmarshalling est automatique et personalisable c'est super
bien documenté et tellement simple http://www.themindelectric.com/ je peux
dire que j'ai pratiqué beaucoup de
middleware,CORBA,RMI,TUXEDO,MQSERIES,CICS et que de tous cela SOAP est
vraiment le plus simple a manipuler du moins avec GLUE ;) A+ Marc ps
(desole pour les fautes j'ai tapez comme un malade) ps de ps GLUE est
gratuit !!!!


A+ marc

Bonjour,

je fais suite aux échanges du 18/02 dernier sur les comparaisons des coûts
de réalisation d'une appli JSP et d'une appli SWING. Ayant fait un bilan
des discussions, j'ai pensé que cela pouvait en intéresser certains.
Ci-joint donc le document RTF. (See attached file: JSP vs Swing.rtf) a+

julien

Bonjour,
Ce document résume assez bien les nombreux points à prendre en compte.
Quelques remarques tout de même sur les points suivants (en se placant
dans le cas d'une application Intranet ce qui est souvent le cas) : -
Finitions du design : Non triviale dû aux particularités des navigateurs .
faux puisqu'un parc informatique est "censé" comprendre des versions
logiciels identiques. - Finitions du design : Peut être rendu complexe par
le manque de formalisation du langage HTML. Qu'entendez-vous par
formalisation ? Si vous parlez de normes, il me semble que l'HTML en est
pourvues. - Connaissances à maîtriser : Nombreux langages : HTML, XML,
Java, (Javascript). Que vient faire le XML là dedans ? Si c'est un moyen
d'échanger des données, il devra aussi être maitrisé dans le cas d'une
application SWING. - Compatibilité :  Dépend des versions des navigateurs
et Dépend du niveau de sécurité des navigateurs (ex : Javascript). ces
points sont à rattacher à la première remarque.

Le point le plus important est qui n'est pas énormément souligné est la
problématique du déploiement. Une application en SWING sur une vingtaine
de postes (le problème de comptabilité peut être résolu aisément) mais
pensez à des applications qui tourne sur plusieurs centaines de postes
(qui parfois peuvent être éloignés géographiquement).

Cela dit c'est un vaste problème sûrement aussi culturel et aussi de
compétences disponibles (il est plus facile de trouver des personnes
maîtrisant HTML,JSP et un peu EJB que des personnes maîtrisant la
compléxité d'une application SWING. Mais nous entrons dans un problème
mettant en cause des problématiques subjectives et d'expériences
professionnelles. Olivier qui vous donne son avis "personnel"


----- Original Message -----
From: <Julien.Piaser@zas.admin.ch>
To: <java@u-strasbg.fr>
Sent: Friday, February 22, 2002 4:03 PM
Subject: Re: Coût de réalisation JSP/SWING




Bonjour,

je fais suite aux échanges du 18/02 dernier sur les comparaisons des coûts
de réalisation d'une appli JSP et d'une appli SWING. Ayant fait un bilan
des discussions, j'ai pensé que cela pouvait en intéresser certains.
Ci-joint donc le document RTF. (See attached file: JSP vs Swing.rtf) a+

julien



**********************************************************************  Ce
message électronique et tous les fichiers joints ainsi que  les
informations contenues dans ce message (ci après "le message"), sont
confidentiels et destinés exclusivement à l'usage de la  personne à
laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci
 de le renvoyer à son émetteur et de le détruire. Toute diffusion,
publication, totale ou partielle ou divulgation sous quelque forme que ce
soit non expressément autorisées de ce message, sont interdites.  

********************************************************************** 
This e-mail, any attachments and the information contained (herein " the
message") are confidential and intended solely for the use of the
addressee(s) if you have received this message in error please send it
back to the sender and delete it. Unauthorized publication, use,
dissemination or disclosure, either whole or partial, of this  message is
strictly prohibited.

Le 22 Feb 2002 Julien.Piaser@zas.admin.ch a écrit :

> 
> 
> Bonjour,
> 
> je fais suite aux échanges du 18/02 dernier sur les comparaisons des
> coûts de réalisation d'une appli JSP et d'une appli SWING. Ayant fait un
> bilan des discussions, j'ai pensé que cela pouvait en intéresser
> certains. Ci-joint donc le document RTF. (See attached file: JSP vs
> Swing.rtf) a+
> 

Très intéressant. Est-ce que tu es OK pour que j'en publie une 
version HTML sur la pseudo-archive ?

(j'ai déjà publié la version "live" :-)

--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com

déploiements Swing: JavaWebStart/JNLP (avec des réserves)
 => avantage JSP (mais pas impossible avec Swing)
critère supplémentaire: internationalisation de l'IHM
 => avantage Swing.

Cdlt,
Alexis

LAMY Olivier wrote:

> Bonjour,
> Ce document résume assez bien les nombreux points à prendre en compte.
> Quelques remarques tout de même sur les points suivants (en se placant
> dans le cas d'une application Intranet ce qui est souvent le cas) : -
> Finitions du design : Non triviale dû aux particularités des navigateurs
> . faux puisqu'un parc informatique est "censé" comprendre des versions
> logiciels identiques. - Finitions du design : Peut être rendu complexe
> par le manque de formalisation du langage HTML. Qu'entendez-vous par
> formalisation ? Si vous parlez de normes, il me semble que l'HTML en est
> pourvues. - Connaissances à maîtriser : Nombreux langages : HTML, XML,
> Java, (Javascript). Que vient faire le XML là dedans ? Si c'est un moyen
> d'échanger des données, il devra aussi être maitrisé dans le cas d'une
> application SWING. - Compatibilité :  Dépend des versions des
> navigateurs et Dépend du niveau de sécurité des navigateurs (ex :
> Javascript). ces points sont à rattacher à la première remarque.
> 
> Le point le plus important est qui n'est pas énormément souligné est la
> problématique du déploiement. Une application en SWING sur une vingtaine
> de postes (le problème de comptabilité peut être résolu aisément) mais
> pensez à des applications qui tourne sur plusieurs centaines de postes
> (qui parfois peuvent être éloignés géographiquement).
> 
> Cela dit c'est un vaste problème sûrement aussi culturel et aussi de
> compétences disponibles (il est plus facile de trouver des personnes
> maîtrisant HTML,JSP et un peu EJB que des personnes maîtrisant la
> compléxité d'une application SWING. Mais nous entrons dans un problème
> mettant en cause des problématiques subjectives et d'expériences
> professionnelles. Olivier qui vous donne son avis "personnel"
> 
> 
> ----- Original Message -----
> From: <Julien.Piaser@zas.admin.ch>
> To: <java@u-strasbg.fr>
> Sent: Friday, February 22, 2002 4:03 PM
> Subject: Re: Coût de réalisation JSP/SWING
> 
> 
> 
> 
> Bonjour,
> 
> je fais suite aux échanges du 18/02 dernier sur les comparaisons des
> coûts de réalisation d'une appli JSP et d'une appli SWING. Ayant fait un
> bilan des discussions, j'ai pensé que cela pouvait en intéresser
> certains. Ci-joint donc le document RTF. (See attached file: JSP vs
> Swing.rtf) a+
> 
> julien
> 
> 
> 	
> ********************************************************************** 
> Ce message électronique et tous les fichiers joints ainsi que  les
> informations contenues dans ce message (ci après "le message"), sont
> confidentiels et destinés exclusivement à l'usage de la  personne à
> laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
> merci  de le renvoyer à son émetteur et de le détruire. Toute diffusion,
> publication, totale ou partielle ou divulgation sous quelque forme que
> ce soit non expressément autorisées de ce message, sont interdites.  	
> ********************************************************************** 
> This e-mail, any attachments and the information contained (herein " the
> message") are confidential and intended solely for the use of the
> addressee(s) if you have received this message in error please send it
> back to the sender and delete it. Unauthorized publication, use,
> dissemination or disclosure, either whole or partial, of this  message
> is strictly prohibited.
> 


-- 
______________________________________________
Alexis Moussine-Pouchkine <amp@france.sun.com>

> critère supplémentaire: internationalisation de l'IHM
>	=> avantage Swing.
Pas necessairement. Une application dont l'IHM est faite en HTML est bien
plus facile a internationaliser. Deja parce que l'HTML est bien moins
gourmand en espace et que le texte est plus libre donc tu n'as pas de
problemes de Layout. D'autre part, je pense qu'il existe bien plus de
pages HTML ecrites dans des langages differents que d'applications Swing.
Enfin, les differents browsers HTML les plus utilises supportent en
general plus de methodes d'entree (IME) que les applications Swing. Pour
ce que j'en ai vu, pour gerer l'entree de texte Japonais dans une
application Swing depuis une station de travail dont l'OS est anglais,
c'est un peu la croix et la banniere non?

D'autre plus, Struts propose un bean permettant de gerer l'extraction de
resources dans les pages JSP, donc tu peux utiliser le meme systeme base
sur les ResourceBundles que dans Swing.

Nicolas



LAMY Olivier wrote:

> Bonjour,
> Ce document résume assez bien les nombreux points à prendre en compte.
> Quelques remarques tout de même sur les points suivants (en se placant
dans
> le cas d'une application Intranet ce qui est souvent le cas) :
> - Finitions du design : Non triviale dû aux particularités des
> navigateurs
.
> faux puisqu'un parc informatique est "censé" comprendre des versions
> logiciels identiques. - Finitions du design : Peut être rendu complexe
> par le manque de formalisation du langage HTML. Qu'entendez-vous par
> formalisation ? Si
vous
> parlez de normes, il me semble que l'HTML en est pourvues.
> - Connaissances à maîtriser : Nombreux langages : HTML, XML, Java,
> (Javascript). Que vient faire le XML là dedans ? Si c'est un moyen
> d'échanger des données, il devra aussi être maitrisé dans le cas d'une
> application SWING. - Compatibilité :  Dépend des versions des
> navigateurs et Dépend du niveau de sécurité des navigateurs (ex :
> Javascript). ces points sont à rattacher
à
> la première remarque.
> 
> Le point le plus important est qui n'est pas énormément souligné est la
> problématique du déploiement. Une application en SWING sur une vingtaine
de
> postes (le problème de comptabilité peut être résolu aisément) mais
> pensez
à
> des applications qui tourne sur plusieurs centaines de postes (qui
> parfois peuvent être éloignés géographiquement).
> 
> Cela dit c'est un vaste problème sûrement aussi culturel et aussi de
> compétences disponibles (il est plus facile de trouver des personnes
> maîtrisant HTML,JSP et un peu EJB que des personnes maîtrisant la
compléxité
> d'une application SWING.
> Mais nous entrons dans un problème mettant en cause des problématiques
> subjectives et d'expériences professionnelles. Olivier qui vous donne
> son avis "personnel"
> 
> 
> ----- Original Message -----
> From: <Julien.Piaser@zas.admin.ch>
> To: <java@u-strasbg.fr>
> Sent: Friday, February 22, 2002 4:03 PM
> Subject: Re: Coût de réalisation JSP/SWING
> 
> 
> 
> 
> Bonjour,
> 
> je fais suite aux échanges du 18/02 dernier sur les comparaisons des
> coûts de réalisation d'une appli JSP et d'une appli SWING. Ayant fait un
> bilan des discussions, j'ai pensé que cela pouvait en intéresser
> certains. Ci-joint donc le document RTF. (See attached file: JSP vs
> Swing.rtf) a+
> 
> julien
> 
> 
> 	
> ********************************************************************** 
> Ce message électronique et tous les fichiers joints ainsi que  les
> informations contenues dans ce message (ci après "le message"), sont
> confidentiels et destinés exclusivement à l'usage de la  personne à
laquelle
> ils sont adressés. Si vous avez reçu ce message par erreur, merci  de le
> renvoyer à son émetteur et de le détruire. Toute diffusion, publication,
> totale ou partielle ou divulgation sous quelque forme que ce soit non
> expressément autorisées de ce message, sont interdites.  	
> ********************************************************************** 
> This e-mail, any attachments and the information contained (herein " the
> message") are confidential and intended solely for the use of the
> addressee(s) if you have received this message in error please send it
back
> to the sender and delete it. Unauthorized publication, use,
> dissemination
or
> disclosure, either whole or partial, of this  message is strictly
> prohibited.
> 


-- 
______________________________________________
Alexis Moussine-Pouchkine <amp@france.sun.com>

----- Original Message -----
From: "Nicolas Sallembien" <Nicolas.Sallembien@ariba.com>
To: <Cc: Cc:java@u-strasbg.fr>
Sent: Friday, February 22, 2002 8:10 PM
Subject: RE: Re: Coût de réalisation JSP/SWING

Salut, une petite réponse pour envenimer encore un peu le débat...
Durant les derniers mois, je travaillais pour une entreprise de vente de
matériel de bureau sur le web (mondus.fr pour ne pas la citer, mais
maintenant je peux : elle a fermé !) et cette entreprise dépendait en fait
d'un groupe européen basé à Londres avec des filiales à Paris et Hambourg.
Et naturellement, le coeur de l'application web était fait en Angleterre,
puis spécialisé dans les différents pays. Et pour cette spécialisation,
nous utilisions des ressources locales, qui étaient traduites par un
mécanisme assez baroque, mais n'utilisant pas Struts. Et globalement, le
résultat était tout à fait identique à celui qu'on peut attendre de la
pire des applications swing : comme le texte n'était pas identifié suivant
la page où il se trouvait, les traductions se faisaient hors contexte,
générant du travail supplémentaire pour les chargés de traduction, ainsi
que de nombreux cas où ce texte ne correspondait à rien. Pourquoi je parle
de ça ? Tout simplement comme introduction à ma réponse à un autre Nicolas
(encore une preuve qu'il s'agit bien du prénom le plus péniblement commun
de France)...

>
> > critère supplémentaire: internationalisation de l'IHM
> > => avantage Swing.
> Pas necessairement. Une application dont l'IHM est faite en HTML est
> bien plus facile a internationaliser. Deja parce que l'HTML est bien
> moins gourmand en espace et que le texte est plus libre donc tu n'as pas
> de problemes de Layout.

C'est bien le seul argument valide. Effectivement, traduire une page web
en entier est des plus simple.

> D'autre part, je pense qu'il existe bien plus de pages
> HTML ecrites dans des langages differents que d'applications Swing.

Tu m'excuseras, mais l'argument du nombre ne me convient pas du tout. La
plupart des pages web sont écrites en anglais, et elles ne sont traduites
*que* lorsque l'auteur n'est pas anglo-saxon.

> Enfin,
> les differents browsers HTML les plus utilises supportent en general
> plus
de
> methodes d'entree (IME) que les applications Swing.

Je ne suis pas du tout d'accord. D'origine, les browsers Netscape et
Microsoft sont livrés avec le pack de langues correspondant à la zone
linguistique de la machine, ainsi, nous avons IE et NN en européen, mais
rarement en sanscrit. De plus, pour passer dans ces langues, il faut
changer le mode d'encodage du texte puisque ces navigateurs n'utilisent
pas l'UNICODE. A contrario, Opera, et Swing, utilisent l'UNICODE. Ainsi,
ta machine virtuelle Java permet de lancer des applications écrites en
japonais, tout comme Opera permet d'afficher les pages japonaises
utilisant l'UNICODE. Par conséquent, si tu consultes les apercus de
NetBeans, tu t'apercevras qu'il existe, si je me souviens bien, un écran
présentant le module d'internationalisation où du texte japonais est
entouré de texte eurpoéen, et même anglais. Le tout, sans changer de
système d'encodage (puisque c'est de l'UNICODE).

> Pour ce que j'en ai vu,
> pour gerer l'entree de texte Japonais dans une application Swing depuis
une
> station de travail dont l'OS est anglais, c'est un peu la croix et la
> banniere non?

Tout comme il peut être invraisemblament complexe d'utiliser une
application écrite en japonais sur une machine française. L'argument n'est
donc pas réellement recevable. > > D'autre plus, Struts propose un bean
permettant de gerer l'extraction de > resources dans les pages JSP, donc
tu peux utiliser le meme systeme base sur > les ResourceBundles que dans
Swing.

Donc, comme les jsps copient Swing, elles sont mieux que Swing, c'est bien
cela ? > > Nicolas

Nicolas Delsaux