RIA et applet

[Sebastien Bordes]

Bonjour à tous,

J'aimerai avoir un petit retour d'expérience des abonnés du JUG.

Utilisez-vous des applets Java pour faire des applications internet
riche communicant avec un serveur ?

Qu'en est-il de la rapidité d’exécution , des nouvelles règles de
sécurité ? etc ...
J'ai cru lire que les règles avait été assouplies depuis mes tests (il
y a presque 10 ans) et qu'il était possible d' écrire sur le disque.

Depuis qu'Oracle a mangé Sun la doc est laissé à l'abandon et les
pages sont pénibles à retrouver (déjà qu'avec Sun c'était pas
l'extase).

Je me me pose des questions sur l'utilité d'un framework pour faire
des applets en mode RIA afin de créer une alternative aux autres
technologies RIA car j'ai été déçu par beaucoup d'entre elles

_ javascript (trop dépendant du navigateur)
_ flex (mono threadé et trainant le gros boulet flash avec des objets
bancals à souhait)
_ Silverlight ( trop MS et code totalement imbitable avec leur MVVM de
fgdfgd)

Merci pour vos réponses

[Olivier Rossel]

Perso, j'utilise avec plus ou moins de bonheur MozSwing qui intègre
un navigateur web dans une appli Swing (et je déploie le tout en Java
Web Start).
Je reste convaincu que c'est une techno intéressante
pour avoir une grande flexibilité d'architecture côté client.

Sun va officialiser cela dans JavaFX 2, avec son WebView.

Maintenant, je suis peut-être hors sujet par rapport à ce que tu recherches.

2011/5/23 Sebastien Bordes <sebastie...@gmail.com>:

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Toulouse JUG.
> Pour envoyer un message à ce groupe, adressez un e-mail à toulou...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse toulouse-jug...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/toulouse-jug?hl=fr
>
>

[stephane...@gmail.com]

Personnellement j'ai été impressionné par la simplicité et la puissance de http://riasuite.canoo.com/demos/index.html .
Couplé à Grails ou SpringMVC c'est chouettos. Sinon have a look sur Griffon, mon coup de coeur.

Le , Olivier Rossel <olivier...@gmail.com> a écrit :

[Sebastien Bordes]

Effectivement JavaFx v2 semble prometteur, la réponse d'oracle à adobe
et MS voici la road map : http://javafx.com/roadmap/
par contre il faudra une nouvelle jvm ...ca va encore se battre à coup
de 97%...

Mon idée était bien de profiter de la puissance de Swing et du
Multithreading de java pour faire de vraies applications RIA avec un
langage client/serveur identique... c'est à priori ce que JavaFX2
prévoit de faire

Java FX (1) a été un échec car il imposait d'apprendre un autre
langage de script ... , reste à savoir si l'implémentation de cette
V2, pourvu qu'elle ne traine pas de gros boulets de la V1

Merci du retour

Sinon ma question sur les applets JAVA tient toujours...

On 23 mai, 15:53, Olivier Rossel <olivier.ros...@gmail.com> wrote:
> Perso, j'utilise avec plus ou moins de bonheur MozSwing qui intègre
> un navigateur web dans une appli Swing (et je déploie le tout en Java
> Web Start).
> Je reste convaincu que c'est une techno intéressante
> pour avoir une grande flexibilité d'architecture côté client.
>
> Sun va officialiser cela dans JavaFX 2, avec son WebView.
>
> Maintenant, je suis peut-être hors sujet par rapport à ce que tu recherches.
>

> 2011/5/23 Sebastien Bordes <sebastien.bor...@gmail.com>:

[Saad El Khlifi]

Swing à toujours souffert d'une mauvaise réputation, lourdeur de dév, un model MVC casse tête.
Mais avec une simple glue d'une JSR 295, et de la JSR 303 et combinées à  qqe moteur de skin, le dév Swing devient une BMW en terme de robustesse,et une ferrari en terme de productivité. voir ce lien :

http://www.universite-du-si.com/fr/conferences/3-usi-2008/sessions/776-java-aussi-productif-que-net-pour-le-developpement-d-application-graphique-n-tiers

c'est très intéressant, j'essaie même de m' inspirer dessus pour construire un model similaire pour mon dév flex

Saad EL KHLIFI
Ing Concepteur Développeur



SQLI RABAT
Tél : 06 63 85 47 72
Site Sqli : http://www.sqli.com
Site perso: http://saadoz.0fees.net

[sebastie...@gmail.com]

Flex est et restera monothreadé car ça serait très couteux a adobe de rajouter le multithread, et à l'époque ou la moindre tablette possède un double cœur, l'utilisation d'une seul processus aboutira irrémédiablement à des ralentissements acceptable il y a 5 ans mais plus maintenant.

De plus enrichir Flex est complexe et assez limité. (Perso j'ai utilisé une surcouche de PureMVC pour bien structurer le code mais c'est assez lourd à comprendre surtout avec tous les événements asynchrone)

il me semble avoir déjà vu Canoo un jour mais le prix est un peu rebutant pour certains projets... sinon cela représente bien l'idée de mon poste.

Donc sur quoi miser Cannoo'like ou JavaFx2 ? et pourras-ton migrer d'un applet swing vers javafx2 ...

Le , Saad El Khlifi <saadel...@gmail.com> a écrit :

> SQLI RABAT
> Tél : 06 63 85 47 72Site Sqli : http://www.sqli.com
> Site perso: http://saadoz.0fees.net
>
>
>
>
>
>
>
>

[Stephane Maldini]

Tu peux tenter http://griffon.codehaus.org/ 

Il s'agit d'un framework basé sur les conventions Grails mais pour faire du Swing ( et même du GTK etc) , de packager l'appli en tant que Jar, Zip , JNLP ou même applet.

Il ne te reste aprés qu'a le coupler à une appli web via webservices standards ou REST ou toute autre technique de communication :) 

C'est un peu moins tout en un que Canoo ULC qui dispose de pas mal de support pour mais c'est carrément bien foutu.

2011/5/23 <sebastie...@gmail.com>

--

Stéphane MALDINI

Consultant 

www.doc4web.com

EMC partner - www.emc.com

--
http://fr.linkedin.com/in/smaldini

[Ludovic Borie]

Pour ma part, j'ai travaillé sur deux projets full applet, et je ne me tournerai vers cette solution que contraint et forcé...

Concrètement, pourquoi faire une applet ? Pour avoir la puissance de Java comme l'a dit Sébastien (Swing, multi-threading entre autre) côté client... 

Donc, on veut faire un client lourd sans les contraintes du déploiement et du versionning... Bon, soit...

Maintenant, voyons les inconvénients:

- Swing, c'est moche... Vous pourrez me sortir tous les looks and feel que vous voudrez, jamais vous n'arriverez à un résultat digne de ce nom pour un utilisateur lambda ! Quelle que soit la plateforme Java proposera une interface qui fonctionne, ok, mais qui sera inhabituelle, dérangeante, et différente de leurs applications habituelles et natives  sous Windows, Mac Os X, ou un linux / GTK... La même interface partout, mais elle ne sera bien nulle part :) Je caricature un peu mais bon...

- L'applet est là pour faire des choses qu'on ne pourrait pas faire autrement... Il devient alors vite tentant de charger ses données à la volée dans son applet, d'afficher plein de choses dynamiquement, et quoi de plus facile avec Swing ? Il est possible que dans mon cas c'était mal foutu, mais au moins c'est révélateur d'une vraie problématique, l'appli est devenue inutilisable très rapidement du fait de l'excès d'échange réseaux...

Mon ressenti global, c'est qu'une applet peut-être pratique pour de petits affichages ponctuels et bien spécifiques, mais que si cette applet grossit un peu trop, nous nous trompons d'architecture...

--

Ludovic Borie

[Nicolas Zozol]

J'avais également fait un bulletin de notes en lignes avec une applet. Plutôt efficace et pas si moche.
Par contre au niveau design marketing et de la gestion de la sécurité, c'est pas génial.

Par exemple pour convertir un fichier Excel, le message "Acceptez-vous une exception de sécurité ?" n'est pas fameux pour des parents d'élèves ou un proviseur.

Ça a quand même l'avantage d'être plus facile à faire que du Javascript quand on a beaucoup de travail client avec une bibliothèque spécifique (par exemple le travail sur les images de Facebook).

Nicolas Zozol
---
Robusta Web Library : Open Source Restful clients and more for Java, Android and GWT.

Productive and simple.

2011/5/23 Ludovic Borie <l.b...@gmail.com>

[Frédéric Cabestre]

Bonjour à tous,

J'entends bien l'argument du déploiement à la charge des clients lourds.
L'applet, le Flex, l'ExtJS ou le <remplir avec votre techno préférée>
représentent zéro effort puisque tout le monde à un navigateur.

Sauf que un coup c'est flash qui fait défaut, un coup c'est ce satané
navigateur que je n'avais pas testé qui plantouille...

Quand à l'argument marteau pilon "swing est moche" je vous renvoie aux
présentations du fondateur de JGoodies pour apprendre qu'une IHM SWT
peut tout aussi bien être à vomir. IntellijIDEA est tout en swing, c'est
donc qu'on peu faire quelque chose de beau avec !

Et La standardisation du Look & Feel me direz vous ? Pour ma part
InetllijIDEA tourne sous Ubuntu Gnome, et la différence avec GTK ne me
choque guère... Mais les goûts et les couleurs. Une application Flex
n'est pas plus "Platform Look And Feel Compliant" que Swing.

Par contre un client lourd à l'avantage de pourvoir travailler avec un
serveur en mode événementiel sans faire de bricolages du type "long
polling" et consort.

Y aurait-il moyen de réhabiliter les clients dits lourds ?

Fred.

[Ivan dobosz]

Salut,

Si vous n'avez pas besoin d'un client lourd type Swing, Eclipse RCP, ....(c'est là qu'un DAT est important)
vous pouvez utiliser JQuery+Firebug qui permet de s'affranchir des problèmes de compatibilité entres navigateurs.
Ce framework révolutionne le développement javascript, c'est une référence maintenant.

Cordialement, Ivan Dobosz.

[Nicolas DEVERGE]

Pour rejoindre l'avis de Frédéric, on peut faire des trucs un peu moins moche, en particuliers grâce à XSwingX (http://code.google.com/p/xswingx/), basé sur SwingX (http://swinglabs.org/). Malheureusement, les liens qui pointent sur java.net sont morts à cause d'Oracle sans doutes...

Pour le dernier client lourd Swing sur lequel j'ai travaillé, on a utilisé Spring Rich Client (http://spring-rich-c.sourceforge.net/) qui intègre ces composants, et qui apporte un certain nombre de service clé en main grâce à Spring (IHM d'authentification avec Spring Security etc...).

Nicolas

2011/5/24 Frédéric Cabestre <frederic...@free.fr>

[Emmanuel Bonnet]

On 24/05/2011 10:41, Fr�d�ric Cabestre wrote:
> Bonjour � tous,
>
> J'entends bien l'argument du d�ploiement � la charge des clients

> lourds. L'applet, le Flex, l'ExtJS ou le <remplir avec votre techno

> pr�f�r�e> repr�sentent z�ro effort puisque tout le monde � un navigateur.
>
> Sauf que un coup c'est flash qui fait d�faut, un coup c'est ce satan�
> navigateur que je n'avais pas test� qui plantouille...
>
> Quand � l'argument marteau pilon "swing est moche" je vous renvoie aux
> pr�sentations du fondateur de JGoodies pour apprendre qu'une IHM SWT
> peut tout aussi bien �tre � vomir. IntellijIDEA est tout en swing,

> c'est donc qu'on peu faire quelque chose de beau avec !
>
> Et La standardisation du Look & Feel me direz vous ? Pour ma part

> InetllijIDEA tourne sous Ubuntu Gnome, et la diff�rence avec GTK ne me
> choque gu�re... Mais les go�ts et les couleurs. Une application Flex

> n'est pas plus "Platform Look And Feel Compliant" que Swing.
>

> Par contre un client lourd � l'avantage de pourvoir travailler avec un
> serveur en mode �v�nementiel sans faire de bricolages du type "long
> polling" et consort.
>
> Y aurait-il moyen de r�habiliter les clients dits lourds ?
Vu sur un projet (aujourd'hui en prod) de grande envergure (> 100 dev)
comme framework pr�sentation Web :
http://www.canoo.com/webexperts/products/ulc/ :
une librairie qui utilise Swing natif cot� browser, avec la
programmation m�tier cot� serveur (tout en minimisant les �changes), ils
appelaient ca du "Rich Thin client" (OK, ca fait oxymoron :-) ).

Une sorte de "GWT" avant l'heure, qui, sans "tirer" tout le code m�tier
cot� client, utilise Swing client plut�t que de g�n�rer du JavaScript
client .
�a n'a pas pris tant que cela au final dans la communaut�, mais
l'approche est int�ressante.

Cdlt,
Emmanuel

[Sebastien Bordes]

Je suis d'accord avec Frederic sur le look and feel, que ce soit en
Swing (L&F), Flex (theme css) ou en Silverlight ( style imbitable ou
via expressionblendstudio), le look de l'application est paramétrable
à volonté et cela reste un problème de temps/compétence comme pour du
webdesign traditionnel (sauf que les resources sont sans doute plus
difficile à trouver).

Après sur de la gestion de renderer/editor et consort, personnellement
je trouve que swing etait assez abouti à l’époque, il manquait juste
un cadre type MVC de niveau supérieur au MVC de chaque composant.
Comparé à Flex ou c'est le foutoir complet à cause de l'héritage des
couches basses de flash
Concernant Javascript et les super scripts de type prototype ou
jquery, il faut quand même reconnaitre qu'à maintenir c'est bien
merdique, entre les différentes versions et les problèmes de
compatibilité et des lignes de code à s'exploser le crane...
Pour Silverlight (partie xaml) je ne vais pas détailler mais toute
modification du look doit passer par leur éditeur graphique
(expression blend) tant le code généré est imbitable.
Pour le RCP/SWT, de nombreux composants sont restés inaboutis et il
faut utiliser le plus souvent la surcouche JFace qui elle même possède
des lacunes et il faut souvent faire des copier coller car les classes
sont déclarés finales.

Avec l'explosion de l'utilisation des tablettes dans le monde
professionnel, je pense qu'il faut passer à l'étape suivante.
Je vais donc continuer mes investigations sur une renaissance des
applets et rester à l'écoute des javafx v2.

Merci pour vos retours!

bon je retourne à ma migration flex4.5

On 24 mai, 10:53, Ivan dobosz <ivan.dob...@gmail.com> wrote:
> Salut,
>
> Si vous n'avez pas besoin d'un client lourd type Swing, Eclipse RCP,
> ....(c'est là qu'un DAT est important)
> vous pouvez utiliser JQuery+Firebug qui permet de s'affranchir des problèmes
> de compatibilité entres navigateurs.
> Ce framework révolutionne le développement javascript, c'est une référence
> maintenant.
>
> Cordialement, Ivan Dobosz.
>
> Le 24 mai 2011 10:11, Nicolas Zozol <nzo...@gmail.com> a écrit :
>
>
>
>
>
>
>
> > J'avais également fait un bulletin de notes en lignes avec une applet.
> > Plutôt efficace et pas si moche.
> > Par contre au niveau design marketing et de la gestion de la sécurité,
> > c'est pas génial.
>
> > Par exemple pour convertir un fichier Excel, le message "Acceptez-vous une
> > exception de sécurité ?" n'est pas fameux pour des parents d'élèves ou un
> > proviseur.
>
> > Ça a quand même l'avantage d'être plus facile à faire que du Javascript
> > quand on a beaucoup de travail client avec une bibliothèque spécifique (par
> > exemple le travail sur les images de Facebook).
>
> > Nicolas Zozol
> > ---

> > Robusta Web Library <http://www.robustaweb.com> : Open Source *Restful
> > clients* and more for *Java, Android and GWT*.
> > Productive and simple.
>
> > 2011/5/23 Ludovic Borie <l.bo...@gmail.com>

> >> Le 23 mai 2011 16:47, Stephane Maldini <stephane.mald...@gmail.com> a
> >> écrit :
>
> >> Tu peux tenterhttp://griffon.codehaus.org/

> >>> Il s'agit d'un framework basé sur les conventions Grails mais pour faire
> >>> du Swing ( et même du GTK etc) , de packager l'appli en tant que Jar, Zip ,
> >>> JNLP ou même applet.
>
> >>> Il ne te reste aprés qu'a le coupler à une appli web via webservices
> >>> standards ou REST ou toute autre technique de communication :)
> >>> C'est un peu moins tout en un que Canoo ULC qui dispose de pas mal de
> >>> support pour mais c'est carrément bien foutu.
>

> >>> 2011/5/23 <sebastien.bor...@gmail.com>

>
> >>> Flex est et restera monothreadé car ça serait très couteux a adobe de
> >>>> rajouter le multithread, et à l'époque ou la moindre tablette possède un
> >>>> double cœur, l'utilisation d'une seul processus aboutira irrémédiablement à
> >>>> des ralentissements acceptable il y a 5 ans mais plus maintenant.
>
> >>>> De plus enrichir Flex est complexe et assez limité. (Perso j'ai utilisé
> >>>> une surcouche de PureMVC pour bien structurer le code mais c'est assez lourd
> >>>> à comprendre surtout avec tous les événements asynchrone)
>
> >>>> il me semble avoir déjà vu Canoo un jour mais le prix est un peu
> >>>> rebutant pour certains projets... sinon cela représente bien l'idée de mon
> >>>> poste.
>
> >>>> Donc sur quoi miser Cannoo'like ou JavaFx2 ? et pourras-ton migrer d'un
> >>>> applet swing vers javafx2 ...
>

> >>>> Le , Saad El Khlifi <saadelkhl...@gmail.com> a écrit :

>
> >>>> > Swing à toujours souffert d'une mauvaise réputation, lourdeur de dév,
> >>>> un model MVC casse tête.
> >>>> > Mais avec une simple glue d'une JSR 295, et de la JSR 303 et combinées
> >>>> à  qqe moteur de skin, le dév Swing devient une BMW en terme de
> >>>> robustesse,et une ferrari en terme de productivité. voir ce lien :
>

> >>>>http://www.universite-du-si.com/fr/conferences/3-usi-2008/sessions/77...

>
> >>>> > c'est très intéressant, j'essaie même de m' inspirer dessus pour
> >>>> construire un model similaire pour mon dév flex
>

> >>>> > Le 23 mai 2011 14:57, stephane.mald...@gmail.com> a écrit :
>
> >>>> > Personnellement j'ai été impressionné par la simplicité et la
> >>>> puissance dehttp://riasuite.canoo.com/demos/index.html.
>
> >>>> > Couplé à Grails ou SpringMVC c'est chouettos. Sinon have a look sur
> >>>> Griffon, mon coup de coeur.
>

> >>>> > Le , Olivier Rossel olivier.ros...@gmail.com> a écrit :

>
> >>>> > > Perso, j'utilise avec plus ou moins de bonheur MozSwing qui intègre
>
> >>>> > > un navigateur web dans une appli Swing (et je déploie le tout en
> >>>> Java
>
> >>>> > > Web Start).
>
> >>>> > > Je reste convaincu que c'est une techno intéressante
>
> >>>> > > pour avoir une grande flexibilité d'architecture côté client.
>
> >>>> > > Sun va officialiser cela dans JavaFX 2, avec son WebView.
>
> >>>> > > Maintenant, je suis peut-être hors sujet par rapport à ce que tu
> >>>> recherches.
>

> >>>> > > 2011/5/23 Sebastien Bordes sebastien.bor...@gmail.com>:

> ...
>
> plus de détails »

[Gabriel Dromard]

Bonjour,

Je voulais dire trois petites choses:

 - Vous n'avez pas évoqué GWT ? Pourquoi ?

 - On peut (mais je suis d'accord ça reste dépendant de la compétence) faire de très belle appli en SWING !

 - Par ailleurs, l'architecture en Java Web Start n'est elle pas la réponse ?? client lourd avec gestion des versions ! Tous ce que l'on demande. Malheureusement je n'ai pas utilisé cette techno en dehors de mes appli perso !

Gabriel

2011/5/24 Sebastien Bordes <sebastie...@gmail.com>

[Sebastien Bordes]

Personnellement je n'ai jamais utilisé GWT, si je ne me trompes pas c'est un 'juste' (aussi puissant soit-il) un générateur de javascript à partir de source java...
Je ne suis pas pour car :
 _ c'est un couche intermédiaire géré par un tiers (certes Google le gére bien)
 _ le javascript ca reste du javascript (et pourtant j'etais un grand fan il y a quelques années)
 _ les ihm sont monothreadés (javascript ne gere pas les thread et de maniere tres moche les evenements différés (setTimeout etc...)
 _ le code généré est le plus souvent difficilement lisible et intelligible
après j'ai bien conscience que google peut fournir un kit de migration vers une autre techno en l'espace de 6 mois mais bon avec des si....

Concernant java web start, justement j'attendais des retex concernant son utilisation avec les applets, car il me semble que ca a bougé car maintenant on peut gérer les applets avec du jws, avant (il me semble) cétait juste pour charger une appli sur le bureau.
La doc d'oracle (si par chance on trouve les bonnes pages) mentionnent cette possibilité avec un script js à charger, après quelques tests ca à l'air de fonctionner (même si je n'aime aps trop appeler des scripts sans savoir ce qu'ils font)

Je voulais également avoir des retours sur les contraintes de sécurité (par exemple le message d'avertissement décrit par nicorama), sur la possibilité de sauver des fichiers en local pour gérer un cache de librairies comme le cache de flash/Flex et de Silverlight qui se substitue au cache du navigateur pour des librairies signés numériquement.

En conclusion de ce débat je pense m'orienter vers du swing en applet en attendant javafx2 (pour éventuellement ensuite migrer).
Je vais regarder de près les possibilités de Canoo qui semble bien pensé mais malheureusement propriétaire.

[Sebastien Bordes]

je viens de jeter un oeil sur griffon et l'idée semble interessante et applique les JSR295-296 pour Swing, par contre l'utilisation de Groovy me semble peu convaincante , j'ai pauer que le code deviennent trop brouillon, ce qui a rendu populaire java est sa relative simplicité

[Florent Garin]

Bonjour,

J'ai beaucoup pratiqué Java Web Start : Windows, Mac, Linux, détection de la JVM, déploiement de lib native, endorsed lib, jar signés, MAJ des certificats, usage derrière des proxies http avec auth NTLM... et ma conclusion est simple JWS n'est pas au niveau.

C'est plein de bugs, de limitations, l'expérience utilisateur est catastrophique, les mises à jour peuvent mal se passer (pas le même fonctionnement si on relance l'appli depuis la page web ou un raccourci)...

Bref à oublier, adobe AIR est mieux mais de toute façon là n'est pas le sens de l'histoire : pure web HTML 5 (jQuery, GWT...) !!

[Olivier Rossel]

sur les dernières JVM, ça va bien mieux, il me semble, non?

2011/5/25 Florent Garin <floren...@docdoku.com>:

[Florent Garin]

Non, l'update 10 (Java 6) était sensé relancer l'intérêt de JWS avec la modularisation de la JVM et quelques autres améliorations mais rien de bien nouveau n'a été en fait apporté. Java Swing et JWS ont des bugs ouverts depuis plus de 10 ans !

La réalité c'est que Sun et encore plus Oracle ne s'intéressent pas à Java sur le client. Il n'y a qu'à voir l'énergie qu'ils mettent sur JavaFx, ils n'arrivent même pas à faire semblant ;=)

[Yann Lorente]

Il faudrait peut-être voir à tempérer le propos : JWS est utilisé par pas mal de projets d'envergure, c'est éprouvé.. en tous cas sans doute beaucoup plus que des frameworks prometteurs mais quoiqu'on en dise moins employés, donc moins fiables.

2011/5/25 Florent Garin <floren...@docdoku.com>

Bonjour,


J'ai beaucoup pratiqué Java Web Start : Windows, Mac, Linux, détection de la JVM, déploiement de lib native, endorsed lib, jar signés, MAJ des certificats, usage derrière des proxies http avec auth NTLM... et ma conclusion est simple JWS n'est pas au niveau.

C'est plein de bugs, de limitations, l'expérience utilisateur est catastrophique, les mises à jour peuvent mal se passer (pas le même fonctionnement si on relance l'appli depuis la page web ou un raccourci)...

Bref à oublier, adobe AIR est mieux mais de toute façon là n'est pas le sens de l'histoire : pure web HTML 5 (jQuery, GWT...) !!

ça dépend un peu du projet, non? on se croirait dans le Quête de l'Anneau là. Il n'y a pas de solution miracle et unique. Pour avoir fait notamment un projet assez important, complètement ajaxifié, assez sexy pour l'époque, mais également des projets plus bruts de décoffrage à base de Web Start, je dirais que le 'sens de l'histoire', c'est aussi le sens de l'histoire du client et de son besoin. Parler de grails à mon client actuel n'aurait aucun sens.

Donc Web Start => solution excellente si dévs Swing sous la main, problématique de déploiement/packaging sur le réseau intra, client peu sensible aux MMI high/tech 'bling bling' mais préférant l'ergonomie standard. Dans les autres cas, il y aura techno plus appropriée.

[Florent Garin]

Je critique davantage JWS que Swing.
En fonction du besoin du client et de l'existant Swing peut se
justifier sans problème.
Par contre JWS comme techno de déploiement, je le répète cette techno
est dans la pratique très très décevante. Je sais malheureusement de
quoi je parle on l'utilise pour notre produit www.docdoku.net et on a
du développer un certain nombre de hacks pour les libs native, API
endorsed...

Je ne connais pas de projets d'envergure (sur l'aspect déploiement
massif) qui l'utilisent.
Par contre, je connais des projets qui l'ont utilisé et qui l'ont
abandonné comme les jeux en ligne suivants :

http://www.puzzlepirates.com/
http://www.runescape.com

Pour eux c'est très important que l'installation et la MAJ se passe
sans anicroche, sinon l'utilisateur est perdu.
Ils ne peuvent pas non plus se permettre de faire du support à des
utilisateurs qui se demanderaient ce qu'ils doivent faire avec le
fichier jnlp !

Maintenant dans le cadre d'un intranet où les utilisateurs en nombre
plus réduit et avec pour eux obligation de faire un minimum d'effort
pour installer le soft, OK JWS peut être acceptable.

--
Florent Garin
Société DocDoku
Consulting, Training, Open Source
Directeur associé
Buropolis - Bâtiment B - 150 Rue Nicolas Louis Vauquelin
31100 Toulouse
Mobile : + 33 (0)6 81 91 01 71
Tel : + 33 (0)5 61 72 24 09
Fax : + 33 (0)9 56 10 29 17
http://www.docdoku.com

[Yann Lorente]

2011/5/25 Florent Garin <floren...@docdoku.com>

Je critique davantage JWS que Swing.
En fonction du besoin du client et de l'existant Swing peut se
justifier sans problème.
Par contre JWS comme techno de déploiement, je le répète cette techno
est dans la pratique très très décevante. Je sais malheureusement de
quoi je parle on l'utilise pour notre produit www.docdoku.net et on a
du développer un certain nombre de hacks pour les libs native, API
endorsed...

Je ne connais pas de projets d'envergure (sur l'aspect déploiement
massif) qui l'utilisent.
Par contre, je connais des projets qui l'ont utilisé et qui l'ont
abandonné comme les jeux en ligne suivants :

http://www.puzzlepirates.com/
http://www.runescape.com

Pour eux c'est très important que l'installation et la MAJ se passe
sans anicroche, sinon l'utilisateur est perdu.
Ils ne peuvent pas non plus se permettre de faire du support à des
utilisateurs qui se demanderaient ce qu'ils doivent faire avec le
fichier jnlp !

Maintenant dans le cadre d'un intranet où les utilisateurs en nombre
plus réduit et avec pour eux obligation de faire un minimum d'effort
pour installer le soft, OK JWS peut être acceptable.

 

On est parfaitement d'accord. Je n'aurais pas l'idée de l'utiliser pour un jeu en ligne :)

[Patrice Trognon]

il est dommage que son intégration n'ai pas été poussée plus loin
car c'était une très bonne alternative aux applets sans tomber dans
le piège de la vm intégrée au navigateur (critique valable aussi
sur flash, on voit l'usine que ça donne). En gros ca fonctionnait pas
trop mal sur windows, dans les autres OS rapidement il ne sait pas
trop quoi faire de ce p***** fichier jnlp.

à l'époque ou ils ont sorti ca cela n'a pas été le seul projet mal poussé
par Sun.

Je ne peux que rejoindre ce que dit Florent.

c'est bien dommage car il existe des extensions a swing qui sont
vraiment super sympa (jgraph, jfreechart, ...).

Perso les approches à base de Flex me séduisent aussi peu :(

Par contre j'avoue avoir été surpris par ta présentation HTML5, et surtout
le "peu" de temps de réalisation pour un rendu aussi sexy.
(même si perso le mode-web déclenchera toujours de fortes nausées chez moi).

Pat

[Florent Garin]

Effectivement c'est vraiment dommage que le boulot n'ait pas été fait
jusqu'au bout.
Sun a été sourd aux critiques sur l'expérience utilisateur comme
l'aspect très intrusif de JWS avec ces nombreuses fenêtres
d'avertissement, le trop visible fichier jnlp...

Et j'ai peur que JavaFx ne suive le même chemin.

[Nicolas Zozol]

2011/5/25 Florent Garin <floren...@docdoku.com>

Effectivement c'est vraiment dommage que le boulot n'ait pas été fait
jusqu'au bout.

Je prend de l'avance sur le Vendredi, mais c'est peut-être là aussi la limite du tout-gratuit.

[Patrice Trognon]

:)

on a aussi vu des technos poussées par du non gratuit qui ont été oubliées du jour au lendemain

car non rentables.

Par contre quelque part, mais la on va reverser dans la critique JEE, le tout gratuit donne

des délires dans le style des centaines de frameworks qui finissent par tuer les frameworks,

c'est du grand n'importe quoi vu le temps d'absorption des technos par les entreprises.

Alors que quand tu as un chef d'orchestre qui dit dans quelle direction on va aller

on voit tout de suite que tout va plus vite et de manière plus cohérente (voir aujourd'hui

le monde iOS et Android).

Je pense plus que le soucis est venu du fait que Sun s'est trop longtemps posé comme

initiateur de specs en laissant l'implémentation aux communautés, si ils avaient fait

l'effort de proposer eux même les implémentations de référence les choses auraient

été un peu plus clair et on aurait perdu moins de temps (les délires du début de JSF vs 

Struts par exemple, ou encore des super technos qui n'ont jamais percé (JINI, ou JWS

comme on en parlait)).

Bon ben voila, on devrait se laisser couler tranquillement jusqu'a vendredi :)

Pat