Le client riche : Quelles technologies ont un avenir ? [Débat] - Page 4

ludosoft · 16/11/2007, 19h01

Tiens c'est délire ça !

Effectivement c'est une bonne idée pour empaqueter une appli Web. Ca fait quelques Mo de moins en mémoire à l'exécution. On peut aussi bloquer les touches de navigation pour éviter le F5 parfois fatal aux appli massivement AJAXisées.

nicorama · 17/11/2007, 14h16

Citation:

Envoyé par hackingcode

le tout via des requêtes HTTP standards post et/ou get.

et PUT et DELETE, c'est fait pour les mamies ?

guslinux · 18/11/2007, 10h22

Perso je trouve que ce qu'il manque c'est une vraie solution d'impression ... c'est encore trop compliqué d'imprimer une bete feuille sans avoir tout un tas de complications ...

La meilleure solution que j'ai trouvé c'est utiliser xulrunner et un client léger en xul pour naviguer ... mais il bug avec les popup

nicorama · 18/11/2007, 10h50

Citation:

Envoyé par guslinux

Perso je trouve que ce qu'il manque c'est une vraie solution d'impression ... c'est encore trop compliqué d'imprimer une bete feuille sans avoir tout un tas de complications ...

La meilleure solution que j'ai trouvé c'est utiliser xulrunner et un client léger en xul pour naviguer ... mais il bug avec les popup

Et puis ca ne marche pas avec IE, non ? Pour faire une version d'impression, il faut avoir un template bien adapté et en faire un pour chaque situation me semble assez complexe - pas tant techniquement, mais c'est surtout au niveau interface où ceux qui ne connaissent niXUL et à peine PDF (ca fait du monde) vont être bien perdus !

Gmail fonctionne très bien avec les retours en arrière. Et pour F5, rappelons qu'à chaque fois que l'on fait une requete (ajax ou pas), il faut mettre des sécurités dès qu'il ne s'agit pas d'un GET tout bête.
On peut très bien clique deux ou trois fois sur un bouton SUBMIT sans ajax.

Traroth2 · 18/11/2007, 13h29

Citation:

Envoyé par yphilogene

Qu'est-ce qui change en fait? Vous vous êtes contenté d'extirper l'application du navigateur pour la mettre dans un viewer fait maison?

Ben, AIR, c'est ça en gros : un moyen de faire tourner du Flex sans navigateur. Et comme la partie html de notre application se limite en fait à inclure l'élément Flash développé avec Flex dans la page, ça a été assez simple à faire.

Traroth2 · 18/11/2007, 13h34

Un truc assez curieux dans les attentes des gens : quand un utilisateur appuie sur précédent alors qu'il est dans une application Flash, ça ne le choque pas que ça revienne à la page où il se trouvait avant de d'arriver sur cette appli, alors qu'avec Ajax, comme ça ressemble à un fonctionnement web traditionnel, ils s'attendent à pouvoir naviguer dans leur application. C'est une grosse différence dans les attentes des utilisateurs, je pense.

ziss · 20/11/2007, 10h17

Salut,
Je m'excuse si je fais hors sujet je veux développer un client "lourd" j'ai fait des recherches et je tombe sur ce débat riche et j'en profite pour poser mon problème.
Je développe une application web et je voudrais intégrer les touches de fonction pour une meilleur intéractivité avec l'utilisateur par exemple faire de tel sorte que la touche F3 lance l'impression de la page courante ou que F1 ouvre l'aide de l'application; mais je ne sais pas comment le faire

j'ai cherché un peu partout mais rien. Si quelqu'un a une idée ou des liens à me passer ça m'aiderais beaucoup;
Je suis à l'écoute.

hackingcode · 20/11/2007, 10h41

Bonjour à tous,

Je reprend ma précedente lettre au père noël pour la compléter et modifier certaines parties.

ce qu'il faudrait en fait c'est une technologie qui fonctionne sur tous les postes clients (mac, windows, linux).

Naturellement celle-ci doit permettre la réalisation d'applications RIA et RDA et mobile performantes avec un seul code (XML de présentation, style et code) pour tous les systèmes et dont le téléchargement serait pris en compte soit directement par le navigateur soit par un plug-in intégré au navigateur soit directement utilisable par un navigateur XML installé en local sur le poste de travail.

Naturellement, les applications interprétées seraient téléchargées dynamiquement à partir de serveurs web de tous types (IIS, J2EE,...) le tout via des requêtes HTTP standards post et/ou get ou autres.

En outre, les données pourraient être accédées via web services, rest, ou un autre flux (csv?) avec un simple process distant de type page asp, jsp, servlet, php,....

De plus, il y aurait un binding automatique des données en provenance du serveur web avec les objets graphiques de façon à ne pas coder les remplissage des champs de saisies ou des widgets situés dans les pages affichées.

Naturellement, il y aurait également la possibiliter de faire du binding inter objet dans une fenêtre ou inter objet entre plusieurs fenêtres.

On pourrait également donner un sens aux données du binding objet --> objets ou objet <--> objet ou objet <--- objet.

Il y aurait également la possibilité de gérer les données que l'on veut poster au serveur web via un simple paramétrage de la présentation et ce, avec les objets de plusieurs fenêtres.

êtes vous toujours d'accord avec ma synthèse ??

ais-je bien résumé les besoins ?

berceker united · 21/11/2007, 10h02

Citation:

Envoyé par Traroth2

Un truc assez curieux dans les attentes des gens : quand un utilisateur appuie sur précédent alors qu'il est dans une application Flash, ça ne le choque pas que ça revienne à la page où il se trouvait avant de d'arriver sur cette appli, alors qu'avec Ajax, comme ça ressemble à un fonctionnement web traditionnel, ils s'attendent à pouvoir naviguer dans leur application. C'est une grosse différence dans les attentes des utilisateurs, je pense.

Ce sont des reflexes. C'est comme le simple clique sur internet et le double click dans windows. Le double click sur internet n'est pas utilisé et c'est pas logique pour l'utilisateur.
Tu as raison de soulever ce point. La seul solution c'est d'ouvrir l'application dans une popup à condition qu'ils n'utilisent pas la touche "back". Mais même cela c'est dérangeant de travailler sur une fenêtre ne ressemblant pas à une fenêtre web. De plus, certain seront déboussolé de ne plus voir leur onglet.

hackingcode · 21/11/2007, 19h19

Lors du développement d'une application web d'entreprise (en intranet), il semble que les utilisateurs soient encore très habitués à leurs applications client serveur traditionnelles (vb , delphi ou autres) ce qui explique leur demande de richesse fonctionnelle en local et leur soif de fenêtrage multiple.

Il est tentant d'essayer de refaire la même chose avec les applications web mais elles sont naturellement limitées de par leur architecture de présentation et leur gestion de cinématique applicative (une seule fenêtre affichée à la fois pour du document centric) ce qui oblige à pratiquer certaines manoeuvres de gestion de contexte fonctionnel et de cinématique applicative (d'ou la multiplicité des framework que l'on a vu fleurir ces dernières années de struts à jsf et j'en passe).

Ajax est, d'une certaine manière, un pont entre les applications web standard et les application multi fenêtrage. Bien entendu, cela résoud certain problème puisque dans une même page on simule plusieurs (mini) pages (par réaffichage généralement) c'est ce qui existe aujourd'hui pour certain RIA ou donnés comme tels par le marketing des éditeurs. Mias cela pose d'autre soucis notamment en terme de maintenance.

Bien entendu et depuis des années, en entreprise les DSI essayent de promouvoir les applications web pour des raisons de TCO et d'homogéneisation du parc applicatif, des moyens de communication et de limitation des coûts de déploiement (entre autre chose).

Pendant longtemp, il n'y a pas eu de solution pratique pour limiter cette résistance au changement des utilisateurs tout en leur offrant des solutions "riches" en multifenêtrage avec l'utilisation des standards du web (ce qui devrait contenter tout le monde du DSi à l'utilisateur) .

Aujourd'hui le client riche évolue dans ce sens et propose des solutions qui semblent matures (le meilleur des deux monde en somme !) Mais la prise en compte du client riche passera obligatoirement par une évangélisation des utilisateurs que nous sommes et la mise en place d'outils d'une plus grande maturité et adaptés à un cycle de développement complet de ce type de solution.

nicorama · 22/11/2007, 09h26

Citation:

Envoyé par hackingcode

il semble que les utilisateurs soient encore très habitués à leurs applications client serveur traditionnelles

Mes utilisateurs, ils sont très content de ne pas avoir de multi-fenetre, de menus et de sous-menus !
Et il ne veulent pas pleins de fonctionnalités et d'options, ils veulent que ce soient le programme qui fasse le boulot, en comprenant leurs besoins.

hackingcode · 22/11/2007, 15h00

Citation:

Envoyé par nicorama

ils veulent que ce soient le programme qui fasse le boulot, en comprenant leurs besoins.

Mais les besoins exprimés par une maitrise d'ouvrage peuvent être simple ou compliqués et un programme qui fait "beaucoup de travail" comporte généralement plus de richesse fonctionnelle donc probablement plus de possibilité graphique. Néanmoins je connais également des utilisateurs telnet qui sont très content de leur interface ;-)

mais j'ai rien contre telnet ;-)))

Traroth2 · 23/11/2007, 12h21

Citation:

Envoyé par berceker united

Ce sont des reflexes. C'est comme le simple clique sur internet et le double click dans windows. Le double click sur internet n'est pas utilisé et c'est pas logique pour l'utilisateur.
Tu as raison de soulever ce point. La seul solution c'est d'ouvrir l'application dans une popup à condition qu'ils n'utilisent pas la touche "back". Mais même cela c'est dérangeant de travailler sur une fenêtre ne ressemblant pas à une fenêtre web. De plus, certain seront déboussolé de ne plus voir leur onglet.

Exact. D'ailleurs, ouvrir une pop-up, c'est ce qu'on a a fait avec Kizoa. Cela dit, on pourrait imaginer que les éditeurs de technos RIA intègrent la gestion de l'historique. Ca serait une fonctionnalité plutôt cool.

Camel LowFilter · 15/01/2009, 20h40

excusez car j'ai pas pu lire tout le débat donc je vais sûrement dire des trucs qui ont déjà été dits...

le rich client web et c'est pas de tout repos pour les sucs gastriques, parce qu'on est forcément dépendant d'une techno qui peut se casser la gueule n'importe quand, on perd un max de temps à anticiper des reconversions, à apprendre des trucs qui au final vous serviront à rien, on peut même se retrouver avec des mois de boulot bons pour la poubelle, des coups à couler sa boîte, on flippe à chaque fois qu'on a des rapports de bugs liés à la techno choisie, etc... tout ça accroît les risques d'ulcère

L'ajax c'est encore la valeur la plus sûre (à mon avis mais je peux me gourrer) car on peut toujours s'adapter aux évolutions des navigateurs web, mais ça coûte cher en temps de travail, à chaque update de navigateur on stresse, bref ça demande plus de boulot que du flash-sliverlight-etc pour un résultat moins bien.

Pour le moment je reste sur le standard flash aprce que c'est nettement plus productif mais vu comme adobe le transforme en usine à bugs (bosser sur la version cs4 devient bien relou) je croise les doigts et j'éspère que ça va pas se vautrer dans l'avenir (même si ça m'a l'air de tenir encore la route pour le moment)

j'ai pas beaucoup de conseils à donner pour faire avancer le shmilblick donc désolé si mon intervention est pas d'une utilité farouche mais ça fait du bien de vider son sac...

nicorama · 23/01/2009, 17h06

Hmmmf, en terme de productivité, je pense que les applets Java détronent tout. Mais c'est pas joli

Camel LowFilter · 25/01/2009, 10h25

ça dépend... l'applet java est plus productif que flash pour un développement sérieux car on peut récupérer plein de libs et on galère pas à trouver des tonnes d'optimisations pour script qui rame

par contre pour des contenus dans lequels on investit pas plus de 2 heures de travail et qu'on demande au graphiste d'apprendre l'actionscript parce qu'on veut pas payer un dev, flash l'emporte haut la main en matière de productivité vu que le graphiste peut faire un tchat en flash d'un coup de drag and drop (et la camelote pas cher ça se vend bien)

devant une concurrence aussi déloyale les applets java pourtant bien meilleurs se sont vautrés, maintenant ça s'intègre mal dans les pages web, ça marche pas sur opera, c'est mort, idem pour tous les super plugins 3d ils se sont pétés la tronche et pour la même raison, contenus trop cher à fabriquer pour ce que ça rapporte

plus c'est pourri et plus l'avenir de la techno est robuste, la seule qui a un avenir assûré c'est le javascript... le reste c'est entièrement dépendant des données économiques et des jeux de concurrence, même le flash il y'a des dev qui refusent d'en entendre parler, pas de techno propriétaire sur leurs sites

nicorama · 26/01/2009, 11h01

Super post, ca sent le vécu

Tommy31 · 26/01/2009, 21h40

Oui, les applets ca fait un peu old scool, surtout avec les technologies alternatives disponibles en java :
- GWT
- JavaFx.

nicorama · 27/01/2009, 08h01

Citation:

Envoyé par Tommy31

Oui, les applets ca fait un peu old scool, surtout avec les technologies alternatives disponibles en java :
- GWT
- JavaFx.

Pas vraiment d'accord. GWT ne donne pas un rendu plus joli qu'une applet avec un L&F valable, et JavaFx est pour l'instant mal documenté et peu soutenu par les IDE, et surtout sera probablement mal acceptée par votre clientèle.

Ensuite Swing est bien plus facile à programmer que GWT et surtout s'il faut débugguer.

Tommy31 · 27/01/2009, 08h20

Citation:

Envoyé par nicorama

Pas vraiment d'accord. GWT ne donne pas un rendu plus joli qu'une applet avec un L&F valable,

Pour moi c'est équivalent, aux animations près (en js les animations sont poussives).

Citation:

Envoyé par nicorama

et JavaFx est pour l'instant mal documenté et peu soutenu par les IDE, et surtout sera probablement mal acceptée par votre clientèle.

Aujourd'hui oui. Mais ne pas négliger l'effet marketing. A voir dans le futur.

Citation:

Envoyé par nicorama

Ensuite Swing est bien plus facile à programmer que GWT et surtout s'il faut débugguer.

Tu m'en vois surpris, parce que Swing n'est pas un modèle de simplicité. En outre, tu peux très bien débugger sous GWT en hosted mode. Certes, il faut faire confiance au code généré (ou à la lib js sur laquelle on s'appuie), c'est là la limite.

18/11/2007, 13h34	#66
Traroth2 Expert Confirmé Inscription : décembre 2003 Messages : 1 659 Détails du profil Informations forums : Inscription : décembre 2003 Messages : 1 659 Points : 3 310 Points : 3 310	Un truc assez curieux dans les attentes des gens : quand un utilisateur appuie sur précédent alors qu'il est dans une application Flash, ça ne le choque pas que ça revienne à la page où il se trouvait avant de d'arriver sur cette appli, alors qu'avec Ajax, comme ça ressemble à un fonctionnement web traditionnel, ils s'attendent à pouvoir naviguer dans leur application. C'est une grosse différence dans les attentes des utilisateurs, je pense. __________________ Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !
	00

20/11/2007, 10h41	#68
hackingcode Invité régulier Inscription : novembre 2007 Messages : 5 Détails du profil Informations forums : Inscription : novembre 2007 Messages : 5 Points : 6 Points : 6	synthèse client riche XML (lettre au père noël) Bonjour à tous, Je reprend ma précedente lettre au père noël pour la compléter et modifier certaines parties. ce qu'il faudrait en fait c'est une technologie qui fonctionne sur tous les postes clients (mac, windows, linux). Naturellement celle-ci doit permettre la réalisation d'applications RIA et RDA et mobile performantes avec un seul code (XML de présentation, style et code) pour tous les systèmes et dont le téléchargement serait pris en compte soit directement par le navigateur soit par un plug-in intégré au navigateur soit directement utilisable par un navigateur XML installé en local sur le poste de travail. Naturellement, les applications interprétées seraient téléchargées dynamiquement à partir de serveurs web de tous types (IIS, J2EE,...) le tout via des requêtes HTTP standards post et/ou get ou autres. En outre, les données pourraient être accédées via web services, rest, ou un autre flux (csv?) avec un simple process distant de type page asp, jsp, servlet, php,.... De plus, il y aurait un binding automatique des données en provenance du serveur web avec les objets graphiques de façon à ne pas coder les remplissage des champs de saisies ou des widgets situés dans les pages affichées. Naturellement, il y aurait également la possibiliter de faire du binding inter objet dans une fenêtre ou inter objet entre plusieurs fenêtres. On pourrait également donner un sens aux données du binding objet --> objets ou objet <--> objet ou objet <--- objet. Il y aurait également la possibilité de gérer les données que l'on veut poster au serveur web via un simple paramétrage de la présentation et ce, avec les objets de plusieurs fenêtres. êtes vous toujours d'accord avec ma synthèse ?? ais-je bien résumé les besoins ?
	00

21/11/2007, 19h19	#70
hackingcode Invité régulier Inscription : novembre 2007 Messages : 5 Détails du profil Informations forums : Inscription : novembre 2007 Messages : 5 Points : 6 Points : 6	back et popup's Lors du développement d'une application web d'entreprise (en intranet), il semble que les utilisateurs soient encore très habitués à leurs applications client serveur traditionnelles (vb , delphi ou autres) ce qui explique leur demande de richesse fonctionnelle en local et leur soif de fenêtrage multiple. Il est tentant d'essayer de refaire la même chose avec les applications web mais elles sont naturellement limitées de par leur architecture de présentation et leur gestion de cinématique applicative (une seule fenêtre affichée à la fois pour du document centric) ce qui oblige à pratiquer certaines manoeuvres de gestion de contexte fonctionnel et de cinématique applicative (d'ou la multiplicité des framework que l'on a vu fleurir ces dernières années de struts à jsf et j'en passe). Ajax est, d'une certaine manière, un pont entre les applications web standard et les application multi fenêtrage. Bien entendu, cela résoud certain problème puisque dans une même page on simule plusieurs (mini) pages (par réaffichage généralement) c'est ce qui existe aujourd'hui pour certain RIA ou donnés comme tels par le marketing des éditeurs. Mias cela pose d'autre soucis notamment en terme de maintenance. Bien entendu et depuis des années, en entreprise les DSI essayent de promouvoir les applications web pour des raisons de TCO et d'homogéneisation du parc applicatif, des moyens de communication et de limitation des coûts de déploiement (entre autre chose). Pendant longtemp, il n'y a pas eu de solution pratique pour limiter cette résistance au changement des utilisateurs tout en leur offrant des solutions "riches" en multifenêtrage avec l'utilisation des standards du web (ce qui devrait contenter tout le monde du DSi à l'utilisateur) . Aujourd'hui le client riche évolue dans ce sens et propose des solutions qui semblent matures (le meilleur des deux monde en somme !) Mais la prise en compte du client riche passera obligatoirement par une évangélisation des utilisateurs que nous sommes et la mise en place d'outils d'une plus grande maturité et adaptés à un cycle de développement complet de ce type de solution.
	00

23/01/2009, 17h06	#75
nicorama Membre Expert Inscription : juillet 2006 Messages : 765 Détails du profil Informations personnelles : Âge : 37 Localisation : France, Haute Garonne (Midi Pyrénées) Informations forums : Inscription : juillet 2006 Messages : 765 Points : 1 054 Points : 1 054	Hmmmf, en terme de productivité, je pense que les applets Java détronent tout. Mais c'est pas joli __________________ Robusta Web Library : Clients RESTful open source pour Java, Android & GWT. API Simple et Productive. Avec style.
	00

26/01/2009, 11h01	#77
nicorama Membre Expert Inscription : juillet 2006 Messages : 765 Détails du profil Informations personnelles : Âge : 37 Localisation : France, Haute Garonne (Midi Pyrénées) Informations forums : Inscription : juillet 2006 Messages : 765 Points : 1 054 Points : 1 054	Super post, ca sent le vécu __________________ Robusta Web Library : Clients RESTful open source pour Java, Android & GWT. API Simple et Productive. Avec style.
	00

16/11/2007, 19h01	#61
ludosoft Membre habitué Ludovic Martin Chef de projet technique Inscription : juillet 2002 Messages : 95 Détails du profil Informations personnelles : Nom : Ludovic Martin Âge : 32 Localisation : France, Gironde (Aquitaine) Informations professionnelles : Activité : Chef de projet technique Secteur : High Tech - Multimédia et Internet Informations forums : Inscription : juillet 2002 Messages : 95 Points : 116 Points : 116	Tiens c'est délire ça ! Effectivement c'est une bonne idée pour empaqueter une appli Web. Ca fait quelques Mo de moins en mémoire à l'exécution. On peut aussi bloquer les touches de navigation pour éviter le F5 parfois fatal aux appli massivement AJAXisées.
	00

18/11/2007, 10h22	#63
guslinux Invité de passage Inscription : avril 2004 Messages : 11 Détails du profil Informations forums : Inscription : avril 2004 Messages : 11 Points : 4 Points : 4	Perso je trouve que ce qu'il manque c'est une vraie solution d'impression ... c'est encore trop compliqué d'imprimer une bete feuille sans avoir tout un tas de complications ... La meilleure solution que j'ai trouvé c'est utiliser xulrunner et un client léger en xul pour naviguer ... mais il bug avec les popup
	00

20/11/2007, 10h17	#67
ziss Invité de passage Inscription : janvier 2006 Messages : 8 Détails du profil Informations forums : Inscription : janvier 2006 Messages : 8 Points : 1 Points : 1	Salut, Je m'excuse si je fais hors sujet je veux développer un client "lourd" j'ai fait des recherches et je tombe sur ce débat riche et j'en profite pour poser mon problème. Je développe une application web et je voudrais intégrer les touches de fonction pour une meilleur intéractivité avec l'utilisateur par exemple faire de tel sorte que la touche F3 lance l'impression de la page courante ou que F1 ouvre l'aide de l'application; mais je ne sais pas comment le faire j'ai cherché un peu partout mais rien. Si quelqu'un a une idée ou des liens à me passer ça m'aiderais beaucoup; Je suis à l'écoute.
	00

15/01/2009, 20h40	#74
Camel LowFilter Membre habitué Inscription : décembre 2007 Messages : 180 Détails du profil Informations forums : Inscription : décembre 2007 Messages : 180 Points : 117 Points : 117	excusez car j'ai pas pu lire tout le débat donc je vais sûrement dire des trucs qui ont déjà été dits... le rich client web et c'est pas de tout repos pour les sucs gastriques, parce qu'on est forcément dépendant d'une techno qui peut se casser la gueule n'importe quand, on perd un max de temps à anticiper des reconversions, à apprendre des trucs qui au final vous serviront à rien, on peut même se retrouver avec des mois de boulot bons pour la poubelle, des coups à couler sa boîte, on flippe à chaque fois qu'on a des rapports de bugs liés à la techno choisie, etc... tout ça accroît les risques d'ulcère L'ajax c'est encore la valeur la plus sûre (à mon avis mais je peux me gourrer) car on peut toujours s'adapter aux évolutions des navigateurs web, mais ça coûte cher en temps de travail, à chaque update de navigateur on stresse, bref ça demande plus de boulot que du flash-sliverlight-etc pour un résultat moins bien. Pour le moment je reste sur le standard flash aprce que c'est nettement plus productif mais vu comme adobe le transforme en usine à bugs (bosser sur la version cs4 devient bien relou) je croise les doigts et j'éspère que ça va pas se vautrer dans l'avenir (même si ça m'a l'air de tenir encore la route pour le moment) j'ai pas beaucoup de conseils à donner pour faire avancer le shmilblick donc désolé si mon intervention est pas d'une utilité farouche mais ça fait du bien de vider son sac...
	00

25/01/2009, 10h25	#76
Camel LowFilter Membre habitué Inscription : décembre 2007 Messages : 180 Détails du profil Informations forums : Inscription : décembre 2007 Messages : 180 Points : 117 Points : 117	ça dépend... l'applet java est plus productif que flash pour un développement sérieux car on peut récupérer plein de libs et on galère pas à trouver des tonnes d'optimisations pour script qui rame par contre pour des contenus dans lequels on investit pas plus de 2 heures de travail et qu'on demande au graphiste d'apprendre l'actionscript parce qu'on veut pas payer un dev, flash l'emporte haut la main en matière de productivité vu que le graphiste peut faire un tchat en flash d'un coup de drag and drop (et la camelote pas cher ça se vend bien) devant une concurrence aussi déloyale les applets java pourtant bien meilleurs se sont vautrés, maintenant ça s'intègre mal dans les pages web, ça marche pas sur opera, c'est mort, idem pour tous les super plugins 3d ils se sont pétés la tronche et pour la même raison, contenus trop cher à fabriquer pour ce que ça rapporte plus c'est pourri et plus l'avenir de la techno est robuste, la seule qui a un avenir assûré c'est le javascript... le reste c'est entièrement dépendant des données économiques et des jeux de concurrence, même le flash il y'a des dev qui refusent d'en entendre parler, pas de techno propriétaire sur leurs sites
	00

26/01/2009, 21h40	#78
Tommy31 Membre Expert Chris Camel Architecte de système d'information Inscription : novembre 2006 Messages : 1 242 Détails du profil Informations personnelles : Nom : Chris Camel Âge : 37 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Architecte de système d'information Secteur : Aéronautique - Marine - Espace - Armement Informations forums : Inscription : novembre 2006 Messages : 1 242 Points : 1 892 Points : 1 892	Oui, les applets ca fait un peu old scool, surtout avec les technologies alternatives disponibles en java : - GWT - JavaFx.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email