Commentaires

1. Le jeudi 8 mai 2008 à 18:15, par Tek

Le coup de l'application qui passe du navigateur vers le bureau c'est génial!

En fait, au tout début je pensais que Air permettrait de le faire du jour où j'ai entendu parler de leur histoire de badge. Le pire c'est que ça serait possible mais il faudrait que Air utilise la même librairie que celle du lecteur Flash, or il embarque la sienne propre. Par contre, rien n'empêcherait au passage du badge vers l'application Air, de préciser que le runtime doive préférer la librairie du lecteur en cours d'utilisation et de conserver le fenêtrage utilisé par le navigateur. Probablement complexe à mettre en œuvre, surtout en multi-plateformes, mais clairement pas impossible.

Ensuite il faudrait un bac-à-sable béton pour garantir que la sécurité de l'exécution soit strictement identique dans Air et dans le navigateur.

2. Le vendredi 9 mai 2008 à 23:31, par switcherdav

Pareil que toi, je ne vois pas trop l'intérêt de cette nouvelle techno.

Aussi géniale et puissante soit elle, pour percer, il faut proposer des outils adaptés et c'est là où Adobe fait fort, le framework Flex et l'environnement auteur Flash sont simples à aborder.

PS : on remarque que chez Sun aussi ils utilisent des Mac !

3. Le dimanche 11 mai 2008 à 14:35, par Erick

@tek : c'est vrai que c'est bluffant le coup du glisser/déposer d'applications. Ca peut sembler gadget, mais finalement c'est un mode d'installation "locale" bien plus rapide que le Badge de AIR. J'imagine que pour cela faut avoir Java installée sur la machine client, après ça semble pas une grosse affaire. C'est vrai que si le runtime AIR est déjà sur la machine, il devrait pas trop être impossible de reproduire ce système d'install express. Vivement la V2...

4. Le dimanche 11 mai 2008 à 15:03, par Erick

@ switcherdav : je suis pas du tout convaincu q çà apportera rien, mais j'attends de voir. Je développe pas encore avec Java, mais jcrois que çà permet quand même pas mal de choses quand même :). Après pour l'édition, çà sera avec eclipse comme Flex. IL manquerait plus qu'un petit plugin avec une vue "design" et puis zou. Mais bon je suis pas sûr que Sun s'interresse déjà au workflow designer / dev... à suivre

5. Le jeudi 3 juillet 2008 à 00:49, par Yam

j'ai demandé à un de nos développeurs pourquoi il préférait Silverlight à Flex, voici son point de vue. J'aimerai bien avoir le votre en réponse puisque vous connaissez mieux Flex.

"Le principe de Flex c'est:

Fichier Flex => Compilateur Flex (en Java) => Génération d'un SWF =>
Transfert sur le navigateur => Exécution

Principe de Silverlight:

Fichier XAML => Transfert sur le navigateur => Exécution

Moi je vois les avantages suivants:

- Comme le fichier XAML (de Silverlight) est du XML, il peut être lu par
des machines et permettre son référencement par exemple (par de
GoogleBot par exemple). Pour Flex, ce qui passe sur le réseau, c'est un
binaire que l'on ne peut pas indexer. Bref, si on utilisait que cela,
c'est la fin de Google.
(ndYAM : bon Ok Adobe vient d'annoncer le référencement de flash dans Google).

- Comme le fichier XAML et du XML, et c'est ce que l'on envoi au
navigateur, cela veut dire que côté serveur, on peut très facilement le
générer dynamiquement avec PHP, Perl... ou n'importe quoi d'autre. Dans
le cas de Flex, si on veut faire cela, il faut créer un fichier Flex sur
le serveur, le compiler et envoyer le résultat (bref, cela coûte très
cher). On verra peut être apparaître des servlets J2E pour faire ça,
mais ça limite à Java et ne change rien à la lourdeur de la tâche.

- Dans le cas de Silverlight, on peut développer ses propres balises (en
incluant des DLL .Net écrite avec ce que l'on veut). Cela veut dire
que l'on peut écrire de chose très complexes (même dynamiquement en PHP)
en enrichissant le langage. Avec Flex, il faut modifier le compilateur
pour arriver au même résultat. Du coup, on doit avoir son propre
compilateur (et on ne suit plus le Flex officiel).

- Avec Silverlight, on peut modifier dynamiquement son arbre d'affichage
en chargeant des nouveaux bout de XAML et cela même depuis JavaScript.
Bref, on peut programmer un peu comme en AJAX aujourd'hui. Avec Flex,
c'est pas possible puisqu'il faut passer par le compilateur.

- Avec Silverlight, on peut choisir son langage de programmation (pour
les extensions pas exemple). Avec certains langages il faut compiler,
mais pour d'autre même pas besoin, c'est à la charge du navigateur
(Javascript par exemple).

- Personnellement, je trouve qu'ActionScript est bien en dessous de C#.
D'ailleurs l'utilisation des langages (et même des binaires .Net) permet
de réutiliser du code provenant d'application de bureau par exemple. On
peu même partage du code entre le serveur et le navigateur (alors qu'en
ActionScript...).

- Flash commence en se libérer (en tout cas il y a des annonces en ce
sens), mais aujourd'hui, il n'y a pas vraiment de lecteur Flash libre
qui tiennent la route (peut être la faute aux spécifications de Flash
qui on beaucoup changé depuis le début)."
Ne vous attachez pas à la forme, c'est juste un échange de mail.
Merci,

Yam

6. Le lundi 7 juillet 2008 à 23:14, par erick

salut Yam,

ton développeur doit sûrement avoir raison, silverlight c'est peut être bien !!!
mais comme on est pas expert je te renvoie vers une mine d'infos ;
www.interfaces-riches.com...

PS : pour du XAML en action :
www.danslesruesdavignon.c...

Allez soit pas timide ! Dis quelque chose...