Discussion :

[Skyounet]

Je suis d'accord avec toi ce serait super sympa. SL apporte un degré d'interactivité avec l'utilisateur assez sympa et le tout couplé avec la puissance de la plateforme .NET. C'est un rêve.

Un site Web en SL par exemple, j'en ai déjà vu quelques uns, c'est super beau, super chouette, bon niveau développement je sais pas encore ce que donne un site de A à Z en SL, mais faut que je teste.

Mais le problème reste quand même le réferencement. Il faudrait vérifier ce que BOUBOU81 a dit, et si c'est vraiment le cas, ce serait génial. A voir.

Dans tous les cas pour moi cette techno (je parle toujours de Silverlight) a un très grand avenir devant elle, j'attends encore et toujours la release de la 1.1 pour m'amuser déjà qu'avec l'alpha je fais des trucs assez chouette, si ils enlèvent les bugs et autres trucs chiants genre la création d'Animation directement dans le code managé qui donne de jolis exceptions, la 1.1 risque de connaitre un bon succès je pense et je l'espère.

[monstroplante]

Il me semblait justement que XAML permettait le référencement contrairement à du flash
(PS: je crois l'avoir entendu lors du silverlight tour)

Quelques éléments de réponse :
http://www.fdeshayes.net/index.php?2...160-ria-et-seo

Ce que je comprend c'est que XAML est potentiellement référencable. Encore faut-il que les moteurs de recherche le fassent.

[neo.51]

Il me semblait justement que XAML permettait le référencement contrairement à du flash

Oui car le xaml c'est du xml, il n'empèche qu'il faut pas croire que google et yahoo vont investir des milliard pour développer un algo et un robot capable d'indexer du silverlight vu le peu de sites qui utilisent cette techno.

Et quand bien même ils le feraient faut pas s'attendre à des résultats aussi pertinent que leurs robots xhtml qui résultent d'années d'expérience...


Le dis pas que SL c'est nul hein, je dis juste que dans le cardre d'un site internet il y a cette considération à prendre en compte.

Par contre pour de l'intranet de suite ça me semble plus sympas.

[monstroplante]

Je suis d'accord avec toi. Et c'est entre autre pour cela que je pense que la généralisation de Silverlight pour les sites web va prendre un peu de temps. Mais je ne pense pas que cela coute "des milliards" de développer la techno nécessaire pour parser de XML et l'indexer. Personellement, j'ai bon espoire que les grands comme google référencent le XAML dans les années à venir. Après, je pense que les interets politiques de chaquns sont finalement le facteur le plus déterminant. Et, sur ce sujet, nous n'avons pas toutes les billes.

[npuzin]

Clairement les winforms ne vont pas disparaitre du jour au lendemain.

Mais la solution d'avenir c'est WPF.

Pour un nouveau projet même si tu risques d'essuyer qq platres avec WPF comme c'est tres recent, ca me parait plus judicieux de partir sur du WPF que sur des winforms.

Et effectivement en regardant plus loin, silverlight 1.1 (avec WPF) deviendra peut etre demain la solution judicieuse pour developper une appli de gestion riche et multiplateforme. Mais il y a du chemin a parcourir encore.

[davcha]

Pour un nouveau projet même si tu risques d'essuyer qq platres avec WPF comme c'est tres recent, ca me parait plus judicieux de partir sur du WPF que sur des winforms.

En fait, personnellement, je me suis posé cette question. Et j'en suis arrivé à la conclusion que WPF est, peut-être, encore un peu jeune pour se lancer corps et âme dedans.
Pour des applis internes ou pour le fun, je dis rien, évidemment, mais pour une appli commerciale où on a tout de même des délais à respecter, winform me semble une solution de développement plus rapide pour le moment. En plus tout le monde ne dispose pas d'un serveur 2003.

Voilà, ceci dit, qu'est-ce qui nous empêche de faire du winform proprement et de basculer ensuite sur du wpf le moment venu ?

[npuzin]

En fait, personnellement, je me suis posé cette question. Et j'en suis arrivé à la conclusion que WPF est, peut-être, encore un peu jeune pour se lancer corps et âme dedans.
Pour des applis internes ou pour le fun, je dis rien, évidemment, mais pour une appli commerciale où on a tout de même des délais à respecter, winform me semble une solution de développement plus rapide pour le moment. En plus tout le monde ne dispose pas d'un serveur 2003.

WPF peut s'utiliser sous XP ou VISTA, il suffit d'avoir le framework 3.0 ou supérieur d'installé. Il n'y a pas de lien avec Windows Server 2003.

Voilà, ceci dit, qu'est-ce qui nous empêche de faire du winform proprement et de basculer ensuite sur du wpf le moment venu ?

Cela va dépendre de la taille du projet je pense. Si tu pars sur un petit projet (<6 mois de développement) eventuellement tu peux rester sur des winforms.
Pour un gros projet, au bout d'un an et 1/2 de développement, tu risques de regretter d'être resté sur des winforms. Et si ton IHM est assez évolué ça va être très couteux de la refaire completement. On passe toujours beaucoup de temps sur les IHM.

En général quand Microsoft sort un produit en release, tu sais que c'est stable.

Pour ma part je n'ai pas de dév client lourd prévu à ce jour, mais je partirais sur du WPF dans tous les cas. Concernant les délais, ils sont de toutes facons toujours trop courts

[davcha]

WPF peut s'utiliser sous XP ou VISTA, il suffit d'avoir le framework 3.0 ou supérieur d'installé. Il n'y a pas de lien avec Windows Server 2003.

En fait je pensais à une application distribuée avec un server.
Ceci dit, c'est vrai que rien n'empêche d'avoir une UI en winform ou une UI console pour le server, et les clients en WPF.

[Thomas Lebrun]

Pour des applis internes ou pour le fun, je dis rien, évidemment, mais pour une appli commerciale où on a tout de même des délais à respecter, winform me semble une solution de développement plus rapide pour le moment.

Pas génial comme argument. Sinon, tout le monde serait encore en train de faire du VB 6 et pas du .NET

Voilà, ceci dit, qu'est-ce qui nous empêche de faire du winform proprement et de basculer ensuite sur du wpf le moment venu ?

Si c'est bien développé, rien ne t'en empêche

[SaumonAgile]

Le problème n'est pas dans le développement, ou la techno en elle-même. Le fait est qu'il n'y a pas de demande de la part des clients pour du WPF. Pour du WCF, WFF, oui, mais WPF non, pour l'instant, ça n'intéresse pas les clients.

[npuzin]

Le problème n'est pas dans le développement, ou la techno en elle-même. Le fait est qu'il n'y a pas de demande de la part des clients pour du WPF. Pour du WCF, WFF, oui, mais WPF non, pour l'instant, ça n'intéresse pas les clients.

Nos clients que ca soit WPF,WCF ou WFF tu leurs parles chinois de toutes facons. Mais effectivement je suis d'accord que le client, il ne verra sans doute pas la difference entre winforms ou WPF.

Voilà, ceci dit, qu'est-ce qui nous empêche de faire du winform proprement et de basculer ensuite sur du wpf le moment venu ?
=> Si c'est bien développé, rien ne t'en empêche

Même si c'est bien développé, le plus long et chiant permet moi l'expression, ça reste toujours les interfaces que tu sois en client lourd ou en client riche ou léger.

Si tu pars sur des winforms au départ, je pense que dans la majorité des cas tu ne reviendras pas dessus. Le client il s'en moque pas mal que ce soit en winforms ou en WPF et tu ne lui factureras pas 2 mois de dev juste pour faire plaisir au developpeur.

[Bluedeep]

Nos clients que ca soit WPF,WCF ou WFF tu leurs parles chinois de toutes facons. Mais effectivement je suis d'accord que le client, il ne verra sans doute pas la difference entre winforms ou WPF.

Je ne suis pas d'accord sur ce point.
En effet, WCF et WFF apporte de la valeur ajoutée aux applications ou une réduction du coût des dev. c'est selon; alors que la valeur ajoutée de WPF, ben, on peut la chercher et la réduction du coût de développement ne me semble pas sauter aux yeux.

[npuzin]

Si on cherche bien on peut trouver un argument que le client entendra comme par exemple le fait que l'application passera mieux dans toutes les résolutions. Mais il te faudra un sacré bon commercial pour vendre des journées après coup sur la réécriture de tes écrans en WPF.

Hors applications ludiques, dans 99% des cas, le client pratiquement la seule chose qui l'intéresse c'est gagner en productivité. Ce qui est a la base la raison d'etre de l'informatique.

Souvent tu vas meme pas reussir a vendre une appli windows a une boite qui a un vieux logiciel de facturation tout pourris en mode terminal juste parce leur logiciel répond tres bien a leur besoin.

Si qq'un a une étude objective a qq part qui montre que WPF permet de gagner en productivité par rapport au winforms je suis preneur.

Je ne suis pas d'accord sur ce point.
En effet, WCF et WFF apporte de la valeur ajoutée aux applications ou une réduction du coût des dev. c'est selon; alors que la valeur ajoutée de WPF, ben, on peut la chercher et la réduction du coût de développement ne me semble pas sauter aux yeux.

Je n'ai pas encore trop regardé WCF et WFF, ce que je voulais dire c'est que souvent le client ce n'est pas son problème, son problème c'est d'avoir un logiciel qui marche c'est tout, il a même pas envie de savoir ce qu'il y a sous le capot. Comme moi quand je vais chercher ma voiture chez le garagiste, je me fiche de savoir ce qu'il a fait, je ne veux meme pas savoir car je ne comprendrai rien, je veux juste savoir si je peux repartir avec ma voiture et combien ca me coute. Si je peux repartir avec je ne rale pas, si c'est pas cher je suis content.

On a pas un métier facile

[Thomas Lebrun]

Hors applications ludiques, dans 99% des cas, le client pratiquement la seule chose qui l'intéresse c'est gagner en productivité. Ce qui est a la base la raison d'etre de l'informatique.

On est tous d'accord la-dessus. Maintenant, si ton client te demande une IHM qui exploite beaucoup la 3D, tu va faire quoi ? Faire du WindowsForms et te faire payer une formation de 3 jours sur DirectX/Direct3D ?

Alors qu'avec WPF, ca roule tout seul....

Le client, que tu lui propose une IHM en WPF, WindowsForms, VB, Java, Cobol, etc, il s'en moque: ce qu'il veut, c'est un produit finit. Maintenant, c'est à toi d'avoir les compétences pour ne pas faire en sorte que ton dev WPF dure 3 mois de plus qu'un dev WindowsForms classique. Et à partir de là, les applications WPF se répandront de plus en plus.....

[npuzin]

Dans mon cas, la fiscalité, la TVA et autres impayés en 2D ca leur convient parfaitement.

Je ne dis pas que WPF ce n'est pas bien, je dis juste que si tu pars sur des winforms, que tu codes bien ou mal, de toutes facons tu ne reviendras pas dessus.

Même pour un éditeur logiciel refaire après coup toute l'interface de son logiciel ça me parait etre cher payé.

[befalimpertinent]

Mais effectivement je suis d'accord que le client, il ne verra sans doute pas la difference entre winforms ou WPF.

Le look d'un soft WPF peut être quand même beaucoup plus moderne et user-friendly qu'un classique Winforms. Je pense notamment à tout ce qui est interaction/animation. Bien sur, un client peut se satisfaire d'une appi classique mais le WPF apporte, à mon sens, une valeur ajoutée non négligeable.

Il n'y a qu'a voir comment les clients réagissent à nos maquetttes réalisées en WPF. Certes il y a un effet tape-à-l'oeil mais c'est le but recherché. En plus, une fois la techno maitrisée, ces maquettes nous prennent moins de temps à développer qu'une Winform pour un résultat visuel bien meilleur. La prochaine étape consiste donc à passer d'une maquette à un véritable soft et la c'est encore en discussion mais le WPF semble prendre l'ascendant. Et je ne pense pas que la boite où je bosse soit la seule dans ce cas.

Malgré tout reste encore les problèmes de performances qui sont pour moi le plus gros frein pour l'instant.

[davcha]

Pas génial comme argument. Sinon, tout le monde serait encore en train de faire du VB 6 et pas du .NET

J'ai dit "pour le moment".
Je pensais notemment au "manque" de certains contrôles, style gridview. Ok, il existe des solutions, comme celle de xceed, mais c'est parfois un peu trop évolué pour ce qu'on souhaite faire.

Tu vas aussi me dire que si le but est de réaliser un contrôle gridview pas très évolué, c'est facile à faire en wpf, et je serais tout à fait d'accord avec toi.
Mais, à l'heure actuelle, double-clicker sur "datagridview" va plus vite que de devoir écrire un contrôle gridview, aussi simple soit-il, en wpf.

Et, une autre chose... Le designer wpf actuellement est pas encore super au point, à ce que j'ai pu en voir (je parle d'expression blend).

[npuzin]

Et, une autre chose... Le designer wpf actuellement est pas encore super au point, à ce que j'ai pu en voir (je parle d'expression blend).

D'après les démo que j'ai vu ca a l'air de bien fonctionner mais c'est clairement un outil destiné à des designers. Autant un designer avec cet outil doit pouvoir des trucs tres beaux, mais un dev a moyen de faire de belles horreurs.

Ca a l'air assez complexe et je vois mal un dev avoir la double compétence design/developpement. C'est comme ci on demandait a un dev d'etre a la fois un pro avec VS et en meme temps avec photoshop.

[Bluedeep]

O Maintenant, si ton client te demande une IHM qui exploite beaucoup la 3D, tu va faire quoi ?

Je ne sais pas dans quel secteur tu travailles, mais personnellement, si il m'arrive de devoir faire face parfois à des demandes "pointues" j'en vois rarement qui concernent les IHM (abstraction faites des graphiques "business"), et jamais de demande d'IHM en 3D (qu'est ce que cela peut apporter en terme de process métier ???? honnêtement, je ne vois pas).

Le client, que tu lui propose une IHM en WPF, WindowsForms, VB, Java, Cobol, etc, il s'en moque: ce qu'il veut, c'est un produit finit.

Là, je penses que tu tombes dans l'excés inverse : le client considère en général comme fondamental l'intégration dans le SI existant et rare sont ceux qui aiment multiplier les technos et les plateforms.

Maintenant, c'est à toi d'avoir les compétences pour ne pas faire en sorte que ton dev WPF dure 3 mois de plus qu'un dev WindowsForms classique. Et à partir de là, les applications WPF se répandront de plus en plus.....

Le problème c'est : qu'est ce que WPF apporte ? pour moi, de ce que j'ai vu jusque là, la réponse c'est : rien.

[Bluedeep]

le WPF apporte, à mon sens, une valeur ajoutée non négligeable.

Laquelle ? (étant bien entendu que quand on parle de valeur ajoutée, c'est quelle amélioration une appli avec une IHM WPF peut apporter en terme de process métier vs un appli Winform).