Discussion :

[CUCARACHA]

Salut,

Je travaille actuellement sur un client winform et, étant plutôt spécialisé dans le web, j'ai quelques soucis pour retrouver mes bébés...

En asp.net, lorsqu'on crée un control utilisateur qui contient des controles utilisateurs, on utilise une technique de propagation des évènnements pour les récupérer dans la page dans laquelle est instancié le controle.

Je n'arrive pas à trouver bubblingevent dans mon controle utilisateur.

Pourriez-vous me dire si cette technique existe en winform ? si oui comment s'appelle la méthode à overrider ?

D'avance merci pour votre aide,

Laurent

[tomlev]

Je suis pas sûr de bien comprendre ce que tu veux faire... il n'y pas d'event bubbling en Windows Forms (mais ça existe en WPF). Quel est ton besoin exact ?

[CUCARACHA]

J'ai un écran composé de plusieurs onglets qui utilisent la même interface graphique mais pas de la même façon.

en gros, deux grilles surmontées d'un système de filtrage et d'un dispositif de pagination.

Controle principal

Filtrage gauche

Grille paginée gauche

Système de pagination

Filtrage gauche

Grille paginée droite

Système de pagination

Lorsque je demande un changement de page je déclenche un event qui doit être capté par la form, donc, je dois propager l'évennement dans le controle parent, puis dans le parent du parent puis dans la form.

Avec bubble event, pas besoin de dupliquer les évennements à chaque couche. On fait remonter l'event et on l'intercepte à l'étage qu'on veut.

C'est exactement ce que je voudrais faire.

C'est clair ?

D'avance merci

Laurent

[tomlev]

OK, et dans la form tu n'as pas de référence directe au contrôle qui déclenche l'évènement, c'est ça ? Dans ce cas il n'y a aucun mécanisme pour automatiser ça, il faut propager manuellement l'évènement...

[CUCARACHA]

Ahhhh que je déteste le dev client lourd (qui porte bien son nom d'ailleur)...

Merci pour cette précision...

[tomlev]

Ahhhh que je déteste le dev client lourd (qui porte bien son nom d'ailleur)...

Je n'en pense pas moins du dev web

Enfin perso l'absence de l'event bubbling en WinForms m'a rarement gêné, et de toutes façons je ne développe plus qu'en WPF, qui le supporte

[CUCARACHA]

Re,

Je ne connais pas bien WPF mais je pense que sans le savoir tu fais du dev web sans le savoir en utilisant cette techno, c'est peut être pour ça qu'elle est très similaire à Silverlight.

Je me demande d'ailleur qui, de la poule ou de l'oeuf a été conçu en premier mais je pense que c'est silverlight.

++

Laurent

[tomlev]

Je ne connais pas bien WPF mais je pense que sans le savoir tu fais du dev web sans le savoir en utilisant cette techno, c'est peut être pour ça qu'elle est très similaire à Silverlight.

Je me demande d'ailleur qui, de la poule ou de l'oeuf a été conçu en premier mais je pense que c'est silverlight.

Effectivement ça ressemble un peu à de l'ASP.NET, mais de loin seulement...
Et il me semble que Silverlight est venu après, d'ailleurs au début ça s'appelait "WPF/E" (pour WPF Everywhere)

[Nathanael Marchand]

Je ne connais pas bien WPF mais je pense que sans le savoir tu fais du dev web sans le savoir en utilisant cette techno, c'est peut être pour ça qu'elle est très similaire à Silverlight.

Wow! Quelle assertion! Non, non, WPF est très très très très loin d'être du web! C'est du pur client lourd qui fait des choses très proches du materiel (comme du Direct3D, des Shaders, etc) impossible en Web.

Je me demande d'ailleur qui, de la poule ou de l'oeuf a été conçu en premier mais je pense que c'est silverlight.

Comme dit par Thomas, Silverlight s'appellait WPF/E avant qu'ils trouvent un nom commercial.

[CUCARACHA]

Ah ok, merci d'avoir un peu enrichi ma culture.
La raison pour laquelle je pensais ça est que Silverlight était donné pour être un "flashbuster".
Corrigez-moi si je me trompe,

la configuration du WPF est bien faite à partir de XAML (soit une extension de XML) ?

les composants WPF savent bien consommer des webservices ?

Le WPF est bien exécuté dans une sorte de framework qui interprète le Xaml ?

Merci

Laurent

[tomlev]

Wow! Quelle assertion! Non, non, WPF est très très très très loin d'être du web! C'est du pur client lourd qui fait des choses très proches du materiel (comme du Direct3D, des Shaders, etc) impossible en Web.

Je pense que Laurent faisait surtout référence au langage XAML, qui a certains points communs avec l'ASPX...

[tomlev]

la configuration du WPF est bien faite à partir de XAML (soit une extension de XML) ?

Bah on peut utiliser XAML pour définir la structure et l'apparence de l'interface graphique, mais c'est pas obligatoire... on peut aussi le faire entièrement en code C# (faut être un peu maso quand même...)

les composants WPF savent bien consommer des webservices ?

Pas les composants WPF eux-mêmes, mais une appli WPF ça reste du .NET, donc oui, tu peux tout à fait appeler des webservices, de la même façon qu'en ASP.NET, WinForms, Console ou n'importe quoi d'autre. En fait l'utilisation de WebServices n'a aucun rapport avec la couche UI...

Le WPF est bien exécuté dans une sorte de framework qui interprète le Xaml ?

Bah c'est exécuté par le CLR, comme n'importe quelle appli .NET...

[Nathanael Marchand]

Ah ok, merci d'avoir un peu enrichi ma culture.
La raison pour laquelle je pensais ça est que Silverlight était donné pour être un "flashbuster".

C'est vrai, ca ne l'est plus trop actuellement. Il est désormais beaucoup utilisé pour les applis LOB (Line Of Business)

la configuration du WPF est bien faite à partir de XAML (soit une extension de XML) ?

Ca n'est pas la configuration, c'est la description des interfaces graphiques qui est en XAML. Ce XAML est ensuite compilé en binaire (en BAML) puis au runtime le framework .net parse se BAML pour instancier les objets et monter l'arbre visuel de l'application. Mais ca revient un peu au même que le designer Winform qui écrit tous les composants dans le .designer.cs

les composants WPF savent bien consommer des webservices ?

Euh? J'ai envie de dire oui et alors? J'ai du mal à voir le rapport. Je peux te faire une console qui consomme des webservices et c'est pas pour autant que je fais du web Tout .Net sait consommer des webservices.

Le WPF est bien exécuté dans une sorte de framework qui interprète le Xaml ?

cf. mon détail plus haut.

[olibara]

Salut a tous je vais sans doute encore un peu plus troller le débat mais je reste tres curieux de ce que vous trouvez comme avantage a WPF

Comme le disais Thomas le développement WEB j'evite a chaque fois que je peux et le design ASPX pour moi c'est berk !
Personellement je n'ai encore rien trouvé de plus facile que le design en WinForm et a chaque fois que j'ai vu des tuto animé expliquant le design XAML j'avais l'impression de revenir 20 ans en arriere
Je comprends que l'on puisse aimer faire du design en XML (avec un bon text editor : comme on peut aimer ecrire en l'assembleur) mais personne n'a encore réussi a me convaincre que cela apportait un meilleurs confort par rapport a WinForm

Je suis plutot convaincu que pour un resultat equivalent le design WPF sera plus long et le resultat moins performant qu'en WinForm

[CUCARACHA]

Salut,

L'ASPX a été créé pour permettre à des développeurs client lourd de se mettre au web sans trop de difficulté. C'est super puissant si on le maîtrise mais pour moi, ça n'est pas du dev web (attendez la suite avant de monter au plafond).

Comme d'hab, ce sont les $$$ qui ont guidé la stratégie de MS lorsqu'ils ont pondu l'ASP.net. Ils se cherchaient, ils avaient le dotnet super prometteur, un tas de développeurs rétissants au web et un potentiel commercial sans limite : le web.

Aujourd'hui, quelques gourous nous ont pondu le premier (enfin, la troisième version du premier) système de développement web : Le MVC.

A la base, le nom MVC ressemble à un design pattern comme MVVM. En fait, c'est la version Microsoft (ou devrais-je dire, la version communautaire Microsoft) de Ruby On Rails.

Si tu es un véritable développeur web (tu sais comment fonctionne les protocoles http et https, tu sais comment fonctionne un serveur web, tu maîtrise XHTML, CSS, javascript, JQuery, JSon, C#, SQL Server (2008 R2 si possible) ou MySQL (si si ça fonctionne parfaitement avec entity framework 4 et le connecteur qui va bien), Entity Framework, POCO T4 et (le petit moteur de rendu qui est une TUERIE TOTALE) Razor, le MVC3 c'est juste MONSTRUEUX.

Je comprends que les développeurs clients lourds soient un peu effrayés par le nombre de compétences qu'il faut aligner pour faire du véritable dev web mais l'investissement vaut vraiment le coup et le plaisir de développer qu'on en retire lorsque tout s'imbrique parfaitement dans ta tête puis dans ton appli...

Bref, c'est vraiment difficile de passer du client lourd au MVC3 mais si vous le faites, vous ne pourrez pas le regretter.

En fait tu as une liberté totale puisque tu peux tout coder (ou décider de t'appuyer sur des composants du marché si tu sens que c'est trop dur).

Dans quelques semaines je vous donnerais un lien vers la dernière application que j'ai faite une MVC3, vous jugerez sur pièces.

Bonne continuation

Laurent

(PS je développe aussi en client lourd mais uniquement sous la torture )

[tomlev]

Salut a tous je vais sans doute encore un peu plus troller le débat mais je reste tres curieux de ce que vous trouvez comme avantage a WPF

C'est marrant, j'ai l'impression qu'on a déjà eu cette discussion

Comme le disais Thomas le développement WEB j'evite a chaque fois que je peux et le design ASPX pour moi c'est berk !

Pour moi aussi, et pourtant j'adore WPF... comme quoi ça n'a pas grand chose à voir

Personellement je n'ai encore rien trouvé de plus facile que le design en WinForm

C'est vrai, WinForms est plus facile... mais aussi BEAUCOUP plus limité. Tant que tu veux faire une petite appli très simple, avec un design "standard", WinForms reste sans doute le meilleur choix, notamment pour la rapidité de développement. Après, dès que tu veux faire un design plus sympa, WPF s'impose. C'est aussi beaucoup plus facile de faire des custom controls (pas des user controls) en WPF : en WinForms c'est carrément galère, tu es obligé de gérer tout le dessin à la main... en WPF tu peux définir l'interface en XAML, comme pour les fenêtres ou les user controls

Je comprends que l'on puisse aimer faire du design en XML (avec un bon text editor : comme on peut aimer ecrire en l'assembleur) mais personne n'a encore réussi a me convaincre que cela apportait un meilleurs confort par rapport a WinForm

D'abord, rien ne t'oblige à coder directement en XAML. Le designer de VS2008 était pas terrible, mais celui de VS2010 est bien meilleur. Et si ça te suffit pas, celui d'Expression Blend est excellent. Donc c'est un mauvais argument...
Perso je préfère coder en XAML, je comprends mieux ce que je fais comme ça. Et j'ai toujours l'aperçu dans le designer pour vérifier que je fais pas n'importe quoi...

Je suis plutot convaincu que pour un resultat equivalent le design WPF sera plus long et le resultat moins performant qu'en WinForm

Encore une fois, oui, tant que tu fais des trucs basiques. Ce n'est pas vraiment comparable, parce qu'il y a plein de trucs que tu pourras jamais faire en WinForms, ou alors très difficilement.

D'autre part, même si le développement initial est plus long, la maintenance et les évolutions sont beaucoup plus rapides en WPF (du moins si tu utilises le pattern MVVM).

J'ai mis un certain temps à franchir le pas, mais maintenant ça me ferait vraiment ch**r de devoir revenir à WinForms...

[tomlev]

(si si ça fonctionne parfaitement avec entity framework 4 et le connecteur qui va bien)

Mmm... pas convaincu. Quand je vois sur les discussions sur les forums (ici et sur Stack Overflow), j'ai l'impression qu'il y a quand même un gros paquet de bugs. Ca n'est pas vraiment anormal en soit, dans la mesure où le provider Linq pour MySQL est encore assez récent et manque forcément de maturité, mais pour l'instant j'y réfléchirais à 2 fois avant d'utiliser Entity Framework avec MySQL.

Pour l'instant, le seul provider vraiment fiable que j'ai vu pour un SGBD autre que SQL Server, c'est celui de SQLite. C'était d'ailleurs un des premiers providers EF non MS (voire le premier). C'est assez impressionnant dans la mesure où c'est développé en hobby par un seul gars...

[CUCARACHA]

C'est assez impressionnant dans la mesure où c'est développé en hobby par un seul gars...

Rhoooo le vilain troll... Bien au contraire, comme l'edmx est dans le tfs, c'est bien plus pratique que de développer dans des procs.

J'ai piloté une équipe de 12 personnes on bossait tous avec EF 4. Il faut être organisé c'est tout.

Le jour où je sentirais que ça rame quelque part, je collerais une petite proc stock.

++

Laurent

[tomlev]

Rhoooo le vilain troll... Bien au contraire, comme l'edmx est dans le tfs, c'est bien plus pratique que de développer dans des procs.

Je comprends pas ta remarque, ni le rapport avec ce que j'ai dit
Je disais juste que j'étais impressionné par le travail accompli par l'auteur du provider SQLite...

[CUCARACHA]

Meaculpa...

Bon, pour être bref, j'ai opté pour le client léger dès 2001 et je ne regrette pas, je trouve qu'il est plus facile de revenir au client lourd lorsqu'on vient du client léger que le contraire.

Pour ce qui est de WPF et Silverlight je n'utilise ni l'une ni l'autre de ces technos (sans doute parce qu’on ne m'a jamais demandé d'en faire) et je parie sur le HTML 5.

Merci pour vos conseils et avis