Version imprimable
30% de temps de dev supplémentaire selon je sais plus quel bloggeur chez microsoft.Citation:
Envoyé par Bluedeep
Ceci dit, wpf doit être vraiment très sympathique quand tu as besoin de réaliser un contrôle assez complexe et très spécifique à un métier donné.
npuzin, de ce que j'ai vu de la version 1 de blend, tu es quand même forcé, dans bien des cas, à trafiquer le code xaml, directement.
Je ne parle pas d'IHM en 3D: ce serait idiot et pas forcément utilisable. Je voulais parler de composants d'IHM en 3D tels que, tu le dit toi-même, des graphiques de données.Citation:
Envoyé par Bluedeep
On est d'accord. Maintenant, si ton client à un SI en .NET et qu'il te demande un SmartClient, il y a peu de chance qu'il veuille du Java. Tu va donc t'orienter vers du Winforms ou WPF ;)Citation:
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.
Visualisation des données, binding puissant, modèles de styles/templates, etc... Tu veux d'autres détails ? ;)Citation:
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.
Oui, volontiers, car pour l'instant je ne suis pas convaincu.(je suis un gros utilisateur de WFF et occasionel de WCF, mais pas de WPF pour l'instant : ceci dit je prépare l'archi d'un nouveau projet qui va démarrer en février, et là, comme il s'agira d'un développement ex-nihilo, je me dis "why not", mais il faut que j'ai quelques arguments pour expliquer que le développement des IHM mettra 30% plus de temps - même si les IHM ne représentent que 20 ou 25% du bidule - sans même parler du problème d'adaptabilité des "resources humaines").Citation:
Envoyé par Thomas Lebrun
- Capacité de visualisation des données
- Moteur de binding extrèmement puissant
- Modèles de styles
- Modèles de templates
- Expérience utilisateur accrue
- Possibilité de migrer "simplement" la version SmartClient en une version Web (XBAP)
- Système de DependencyObject/DependencyProperty
- Affichage vectoriel
Fais des recherches sur tout ca et cela devrait aider à convaincre (suivant les besoins bien sur ;))
- Capacité de visualisation des données : comme dis et redis précédement la 3D dans ma boite ca ne servira jamais c'est une certitude absolue, et pour representer un graphe en 3D tu n'as pas besoin de WPF des outils existent depuis la nuit des temps pour faire ca
- Moteur de binding extrèmement puissant : mouais eventuellement ca me parle par contre faut pas que ca utilise LINQ TO SQL car cela ne fonctionne que sous SQL Server pour l'instant
- Modèles de styles : j'en parlerai a mon cheval
- Modèles de templates : et a mon hamster
- Expérience utilisateur accrue : combien d'xp pour le niveau suivant ?
- Possibilité de migrer "simplement" la version SmartClient en une version Web (XBAP) : mouais le truc c'est que généralement tu ne changes pas en cours de route
- Système de DependencyObject/DependencyProperty : connais pas
- Affichage vectoriel : ok, cet argument je le prends je pense pouvoir le vendre a mes utilisateurs
Bref tu l'auras compris je me suis documenté, je ne suis pas expert en WPF mais j'en sais assez pour voir que ca ne va pas changer ma vie et au contraire si ca prend plus de temps pour faire la meme chose, j'attendrai que d'autres essuient les platres avant moi avant de me lancer
Et bien tu t'es mal documenté d'après ce que je vois de tes réponses....Citation:
Envoyé par npuzin
OK, ce n'est pas forcément un argument valable pour tous les projets mais dans certains, cela s'avère un point clé....Citation:
- Capacité de visualisation des données : comme dis et redis précédement la 3D dans ma boite ca ne servira jamais c'est une certitude absolue, et pour representer un graphe en 3D tu n'as pas besoin de WPF des outils existent depuis la nuit des temps pour faire ca
OK donc là, c'est comme si on parlait de carottes et de petits pois... Quel rapport entre WPF et LINQ To SQL ? Tu connais beaucoup de techno où pour faire du binding entre élément de l'IHM, il te faut juste une ligne de code ? Pareil pour faire du binding sur du XML: avec WPF, cela se fait en 3-4 lignes de codes....Citation:
- Moteur de binding extrèmement puissant : mouais eventuellement ca me parle par contre faut pas que ca utilise LINQ TO SQL car cela ne fonctionne que sous SQL Server pour l'instant
OK, à priori, le fait de pouvoir changer de style à la volée, de pouvoir définir, de A à Z, l'apparence de tes contrôles, etc... ne t'intéresse pas ? Soit, après tout, si tu es content des IHM sobres que l'on génères en WindowsForms (bien que certaines soient très classes mais nécessites des développement personnalisés donc plus de temps de dev), alors dans ce cas, je ne dis rien.Citation:
- Modèles de styles : j'en parlerai a mon cheval
- Modèles de templates : et a mon hamster
D'accord, je vois le genre: toi, cela ne te dérange pas de bosser sur une application qui est n'est pas pratique/agréable à utiliser. Tant que ton application est faite et déployée, tu t'en fiches: le fait que les users ne l'utilisent pas parce qu'elle n'est pas ergonomique, etc... ne te dérangent pas plus que ca.....Citation:
- Expérience utilisateur accrue : combien d'xp pour le niveau suivant ?
Un petit conseil: avant de te lancer dans l'IHM de ton application, renseigne toi auprès des utilisateurs pour savoir comment ils aimeraient l'application. Dans bcp de cas, il te demanderont des choses qui:
- ne seront pas "out of the box": pas simple à mettre en place donc besoin de dev en plus
- facile à faire avec WPF mais c'est vrai, c'est une nouvelle techno.
Dans les 2 cas, il y aura besoin de dev en plus.....
Possible mais tu le dis toi-même: "généralement". Ce qui veut dire que cela peut arriver....Citation:
- Possibilité de migrer "simplement" la version SmartClient en une version Web (XBAP) : mouais le truc c'est que généralement tu ne changes pas en cours de route
Ah ? Pourtant, tu as fais des recherches sur WPF ? ;) C'est tout de même un des concepts les + importants de WPF :)Citation:
- Système de DependencyObject/DependencyProperty : connais pas
Bref, à la vue de tes réponses, je me demande ce que tu veux dire par: "Je me suis documenté"... En effet, une vraie recherche passe par l'interrogation d'Internet/des livres mais également l'analyse des besoins des users..... A te lire, j'ai l'impression que tu es ancré dans l'idée: "WPF, c'est pas bien, faut pas l'utiliser". A cela, je ne répondrais qu'une chose: Avant de critiquer, il faut essayer ;)
C'est pas nouveau le binding ca fait depuis le framework 1.1 que tu peux binder en 1 ligne une datasource a une grille.Citation:
Tu connais beaucoup de techno où pour faire du binding entre élément de l'IHM, il te faut juste une ligne de code ? Pareil pour faire du binding sur du XML: avec WPF, cela se fait en 3-4 lignes de codes....
Pour les IHM on arrivera pas a se mettre d'accord mais c'est pas grave. Juste il ne faut pas confondre apparence et ergonomie. Si tu ajoutes des anim partout dans ton appli ok, ca sera plus beau mais a la limite j'ai envie de dire que tu perdras en ergonomie.
Si ton utilisateur a par exemple besoin de saisir le compte rendu de son activité du jour, comme tous les jours, je t'assure que si tu lui met un bouton qui bouge il va raler car ca va lui faire perdre du temps.
Au contraire. Un bouton qui "bouge" est une bonne manière de confirmer où se trouve le curseur de la souris. Et là, en définitive, ça signifie que ton client est content de ce bouton, parce que c'est sécurisant.Citation:
Envoyé par npuzin
Ceci dit, il a pas besoin de danser la samba le bouton.
Je pense que tu confonds le concept WPF et le concept Adobe Flash, l'idée du WPF n'est pas de mettre des animations partout, mais de proposer un nouveau modèle de développement où le design n'est pas limité par des contraintes techniques. Essaie de faire une application avec un visuel WMP 11 en winforms pur (pas de photoshop), et tu vas comprendre l'intérêt du WPF.Citation:
Envoyé par npuzin
Bonjour
Bon, reprenons (dans le calme) :
Il est possible que cela apporte quelque chose, mais j'ai un peu de mal à m'imaginer quoi. En effet, a priori, une IHM ne connait aucune source de données (je ne veux pas voir trainer de "System.Data" dans les classes IHM). Tout ce qu'elle est susceptible de binder ce sont des listes d'objets métiers; donc qu'apport ce binding "super-puissant" ? (hormis celui permis par les DependencyProperties, qui évite en effet le codage de chaine d'événements en cascade, mais strictement rien n'empêche de l'utiliser avec du Winform).Citation:
Envoyé par Thomas Lebrun
Ben, je ne sais pas si ça m'intéresse ou non, mais j'avoue que je n'en vois pas sur le moment l'utilité - peut être que je me trompe ? à voir "on the field".Citation:
OK, à priori, le fait de pouvoir changer de style à la volée, de pouvoir définir, de A à Z, l'apparence de tes contrôles, etc... ne t'intéresse pas ?
Là, je pense que tu tombes dans un travers assez fréquent : confusion entre ergonomie et convivialité.Citation:
D'accord, je vois le genre: toi, cela ne te dérange pas de bosser sur une application qui est n'est pas pratique/agréable à utiliser. Tant que ton application est faite et déployée, tu t'en fiches: le fait que les users ne l'utilisent pas parce qu'elle n'est pas ergonomique, etc... ne te dérangent pas plus que ca.....
C'est un concept 3.0 très important; ce n'est pas un concept uniquement WPF.Citation:
Ah ? Pourtant, tu as fais des recherches sur WPF ? ;) C'est tout de même un des concepts les + importants de WPF :)
Oui c'est sur que ce n'est pas valable à tous les coups, je te l'accorde.Citation:
Envoyé par Bluedeep
Je ne vois pas où est la confusion entre ces 2 notions: une application ergonome est conviviable donc agréable à utiliser. Comme le souligne davcha, il y a des petits effets, sans doute assez inutile aux premiers abords, qui rendent l'application plus ergonomique donc plus conviviable.Citation:
Là, je pense que tu tombes dans un travers assez fréquent : confusion entre ergonomie et convivialité.
A part WPF et WF, les autres APIs (WCS et WCF) du FX .NET 3.0 n'utilisent pas (mais je me trompe p-e) les DependencyObjects/DependencyProperty. ;)Citation:
C'est un concept 3.0 très important; ce n'est pas un concept uniquement WPF.
De plus, lorsque je dis que c'est un concept très important de WPF, c'est que c'est le cas: sans ces notions, adieu le binding, etc...
Non, pour moi ce sont deux notions disjointes. On nous demande de produire des applications ergonomiques (au sens propre : améliorant la productivité du poste de travail) pas des applications conviviales. Si elles sont conviviale, je t'accorde que c'est pas plus mal, mais ce n'est pas le but primaire. Si elles sont conviviales sans être ergonomiques (cas fréquent avec les applications web), il y a un problème.Citation:
Envoyé par Thomas Lebrun
Je ne fais pas de blocage sur WPF (j'insiste) mais je demande à voir.Citation:
Comme le souligne davcha, il y a des petits effets, sans doute assez inutile aux premiers abords, qui rendent l'application plus ergonomique donc plus conviviable.
WFF et WPF exposent chacun une version des Dependency* (peut être est-ce unifié en 3.5 ?), mais rien n'empêche d'utiliser ces objets "hors contexte".Citation:
A part WPF et WF, les autres APIs (WCS et WCF) du FX .NET 3.0 n'utilisent pas (mais je me trompe p-e) les DependencyObjects/DependencyProperty.
Vu comme cela, oui. Mais c'est tout aussi fondamental pour WFF (on peut faire communiquer des Activities sans cela, mais les problèmes lors de la persistance des flux deviennent assez insurmontables).Citation:
De plus, lorsque je dis que c'est un concept très important de WPF, c'est que c'est le cas: sans ces notions, adieu le binding, etc...
Une application ergonomique est une application intuitive, facile et rapide à utiliser et enfin une application "sécurisée" qui empêche l'utilisateur de faire des betises.
Si a un endroit le copier / coller ne marche pas c'est un probleme d'ergonomie.
Ou encore si tu dois forcément quitter un écran pour aller voir une info pour revenir ensuite, il y a un problème d'ergonomie.
L'apparence fait partie de l'ergonomie mais ca n'est vraiment pas le point crucial.
Je te rejoins entièrement la dessus.Citation:
Envoyé par npuzin
J'ai lu un peu (vaguement) le débat et d'après ce que j'ai pu lire je trouve que ce débat n'a pas vraiment lieu d'être...
Tout simplement car les winforms resteront bel et bien la, et encore pour longtemps dans les PME.
Au niveau de ce qui est grand public, ca devrait aller un peu plus vite et on devrais voir de moins en moins de winforms c'est clair et c'est tout à fait normal car WPF tape à l'oeil.
A mon avis aussi, certaines PME qui doivent afficher des rapports, des graphes,... devraient s'intéresser assez vite à WPF (d'après mes tests il est très facile de créer un control pour faire des graphes, beaucoup plus facile qu'en winform).
De toute façon, l'avenir nous diras ce qu'il se passera, même si j'ai un avis plutôt pro-WPF je pense que les winforms ont encore un bel avenir devant eux... ^^
Dans les grands comptes aussi : ils ne refondent pas leurs appli tous les 4 matins :D (j'ai pas de PME dans mes clients, donc pas d'opinion sur leur comportement vis à vis des nouveautés microsoftiennes).Citation:
Envoyé par SoBaKa
On débat en fait pour savoir si on a intérêt ou non à partir sur du WPF sur nos nouveaux projets professionnels qui arrivent.Citation:
J'ai lu un peu (vaguement) le débat et d'après ce que j'ai pu lire je trouve que ce débat n'a pas vraiment lieu d'être...
Moi c'est l'inverse ^^ (et on travaille encore avec le framework 1.1 et j'ai été engagé car ils comptent passer doucement au framework 2)...Citation:
Envoyé par Bluedeep
Et je pense qu'une grosse entreprise a tendance à s'intéresser plus facilement aux nouvelles technos...
Maintenant c'est certains que c'est pas une entreprise qui travaille dans la finance ou quelque chose du genre ne va pas s'intéresser facilement aux nouvelles technos surtout quand on sait que certains travaillent encore en COBOL...
Sinon pour compléter mon avis au sujet de WPF, je pense quand même qu'un Développeur (.NET) à intérêt à s'y intéresser un minimum... et ne pas tout refuser en block comme certains le font dés qu'il y a quelque chose de nouveau et qui ensuite sont obligé de s'y intéresser par la force des choses...
Ben, je suis un peu dans ce secteur et détrompes toi (WFF à donf, par exemple :D ) mais on (enfin je) est pas convaincu de l'apport de WPF en revanche.Citation:
Envoyé par SoBaKa
Normal, WPF n'a pas toujours un intérêt. Comme je sais plus qui l'a raconté dans son blog, quelqu'un lui avait demandé lors d'une conférence : "nous n'avons aucun intérêt pour les applications flashy, pourquoi devrais-je passer au WPF ?".Citation:
Envoyé par Bluedeep
Sur le coup, le gars n'avait pas sû répondre, et puis après mûre reflexion, il a répondu au gars, sur son blog, que WPF n'est pas censé remplacer WinForms, mais simplement ajouter des possibilités supplémentaires. Et que dans le cas précis du gars qui lui avait demandé (qui a un peu le même profil que toi, Bluedeep, c'est à dire un dev pour des grosses entreprises qui touche relativement peu à la relation client, mais énormément au fonctionnement interne de l'entreprise), il n'avait que très peu d'intérêt pour WPF, s'il était déjà pleinement satisfait de WinForms.
Et en définitive, ceci est loin d'être faux. WPF n'a simplement pas vocation à remplacer totalement WinForms. D'ailleurs, on peut intégrer du WPF dans une appli WinForms et du WinForms dans une appli WPF, alors...
Simplement, certaines choses sont beaucoup, beaucoup, beaucoup plus simples et rapides à réaliser en WPF qu'en WinForms, et ce pour un résultat souvent meilleur.
Un exemple "tout con" : l'affichage d'une liste sous forme de cartes de visite, par exemple. Ou encore l'affichage de plus d'une seule information dans une combobox.
(je me permets un petit HS : dans quel genre d'applis tu utilises WFF, Bluedeep ? Et pour réaliser quel genre de processus ? Je demande, parce que c'est un sujet qui m'intéresse beaucoup, mais j'ai un peu de mal à entrevoir ce qu'apporte concrètement WFF, n'ayant pas eu l'occasion d'utiliser de workflow jusqu'à présent... Je me dis que je passe peut-être à côté d'un truc merveilleux)