Discussion :

[Skyounet]

Non pas MDI ! grrrrrrrrrrrrrrr

MIDI = Musical Instrument Digital Interface
C'est une norme qui permet d'envoyer des messages aux instruments de musiques et ... ben de faire plein de choses en fait

Ca doit être faisable avec un peu d'automation COM et une application Silverlight en OOB Trusted.

Autrement ce n'est pas possible et ne le sera pas. La "faute" à la sandbox qui permet de rouler les applications SL de manière protégés. Imagnies-tu un site web qui pourrais accéder à ton matériel sans rien demander ?

Ben il faut penser WEB aussi ! et diviser le code à télécharger par 3, tu finis par éteindre une centrale atomique ! Bon t'as raison, ça non plus ça n'interesse personne

Bah niveau web j'ai rarement vu un site web asp.net codé uniquement en C# et sans une seule ligne de HTML.

La séparation de l'interface (Xaml) et du code permet une modularité extrême. J'imagine bien le bordel avec une interface uniquement écrite en C# pour changer la couleur d'un bouton ou remplacer un Grid par un Canvas

Et pour terminer, d'où tiens tu le fait que le Xaml multiplie la taille du xap par 3 ?

[Navedac]

Et pour terminer, d'où tiens tu le fait que le Xaml multiplie la taille du xap par 3 ?

J'ai fais des tas d'essais.
C'est facilement démontrable et reproductible.
Si tu dézip un XAP, et que tu l'édites, tu vois le XAML en clair dans la DLL Silverlight. J'en ai déduit (à vérifier avec un pro) que le XAML n'est pas compilé.
Coder l'interface directement permet de diminuer par 3 la taille du code.
(Peut être qu'on peut faire mieux, mais moi je n'y suis pas parvenu)
Ca explique aussi la présence du mini-language pour le vectoriel.
Des fois je fais juste un binding sur la propriété path.data. C'est une technique
hyper efficace, je vous la recommande.

[Golzinne]

Une amélioration de l'export/reporting.

Ca c'est vraiment ce qui manque pour faire des business applications !

Rapports Crystal reports ou similaires.
Possibilité de créer des PDF "efficaces" qui ne prennent pas 2MB par page.
Export vers Excell sans être OOB.

[bellak]

pour moi , le temp de calcul :
si Silverlight 5 integre le calcul parallel ca sera top , on peux creer et gerer des donnees du vrai business application

[davrous]

J'ai fais des tas d'essais.
C'est facilement démontrable et reproductible.
Si tu dézip un XAP, et que tu l'édites, tu vois le XAML en clair dans la DLL Silverlight. J'en ai déduit (à vérifier avec un pro) que le XAML n'est pas compilé.
Coder l'interface directement permet de diminuer par 3 la taille du code.
(Peut être qu'on peut faire mieux, mais moi je n'y suis pas parvenu)
Ca explique aussi la présence du mini-language pour le vectoriel.
Des fois je fais juste un binding sur la propriété path.data. C'est une technique
hyper efficace, je vous la recommande.

Hello,

Non, c'est faux, le XAML est parsé et génère bien du code compilé (IL) à la fin. Donc, il n'y aucun intéret à ne pas passer par le XAML pour la description de l'interface en WPF ou Silverlight. Cela ne multiplie en rien la taille des XAP. Je ne sais pas d'où l'on sort tout cela !

Au final, que l'on code l'interface en "dur" en C# ou VB.NET ou en XAML, cela produit le même IL. Par contre, on revient à l'age de pierre si l'on code son interface en code-behind...

Bye,

David Rousset
Microsoft France

[Navedac]

Hello,

Non, c'est faux, le XAML est parsé et génère bien du code compilé (IL) à la fin. Donc, il n'y aucun intéret à ne pas passer par le XAML pour la description de l'interface en WPF ou Silverlight. Cela ne multiplie en rien la taille des XAP. Je ne sais pas d'où l'on sort tout cela !

Au final, que l'on code l'interface en "dur" en C# ou VB.NET ou en XAML, cela produit le même IL. Par contre, on revient à l'age de pierre si l'on code son interface en code-behind...

Bye,

David Rousset
Microsoft France

Alors peut être que je n'ai pas les bons paramètres de compilation ?

Donc, je prend un fichier XAP, je le renomme en ZIP, je l'ouvre.
Le fichier contient la *.dll Silverlight.
J'ouvre la *.dll Silverlight avec le bloc-note.
Je vois le code XAML en "clair" dans la *.dll.

Est ce que quelqu'un peut faire la même manip et apporter des éclaircissements ?

Merci

(Sinon je ferai un squellete de projet bidon pour démontrer (ou pas) ce phénomène. Ca peut servir à tout le monde)

[davrous]

J'aimerai un amélioration de la relation client/base de données.
Mettre en place un système "synchrone" pour l'accès aux données.
Amélioration des RIA avec la possibilité d'étendre les entités côté Silverlight. (je ne sais pas si c'est possible, sinon j'ai pas trouvé...)

Ca serait bien qu'il y ai un peu plus de templates disponibles (Design).

Une amélioration de l'export/reporting.

un binding plus approfondi sur les contrôles (supérieur à 2 niveaux, sans passer par les converters).

Une meilleur compression du xap (automatique).

Je pense que Micro$oft va trouver les bonnes améliorations pour mettre à plat Flex.

Hello,

As-tu jeté un oeil à WCF RIA Services pour Silverlight 4 ? Si non, je t'invite à regarder mes tutoriaux à ce sujet qui devraient répondre à une grosse partie de tes besoins : http://blogs.msdn.com/b/davrous/arch...e-de-code.aspx

Sinon, je pense que c'est une abberation de vouloir une connexion synchrone dans un contexte d'applications RIA. D'une manière plus générale, les tendances autour du cloud et la nécessité d'utiliser les processeurs multi-coeurs implique une programmation asynchrone. Pour résoudre cette complexité que tu indiques à juste titre, RIA Services propose quelques solutions en utilisant le binding de Silverlight et les ObservableCollection. Il existe d'autres approches récentes et intéressantes comme F# ou le Reactive Framework (RX). L'idée est de toutes ces approches est d'avoir un code à lecture séquentiel mais pourtant asynchrone.

David Rousset
Microsoft France
PS : moi aussi je sais des trucs sur Silverlight 5

[davrous]

Alors peut être que je n'ai pas les bons paramètres de compilation ?

Donc, je prend un fichier XAP, je le renomme en ZIP, je l'ouvre.
Le fichier contient la *.dll Silverlight.
J'ouvre la *.dll Silverlight avec le bloc-note.
Je vois le code XAML en "clair" dans la *.dll.

Est ce que quelqu'un peut faire la même manip et apporter des éclaircissements ?

Merci

(Sinon je ferai un squellete de projet bidon pour démontrer (ou pas) ce phénomène. Ca peut servir à tout le monde)

Tu as raison! En fait en WPF, le XAML est parsé et compilé en BAML à la compilation. En Silverlight, c'est manifestement différent. Du coup, tu me mets un énorme doute. Je travaille la question et je reviens vers vous.

David

[Navedac]

Tu as raison! En fait en WPF, le XAML est parsé et compilé en BAML à la compilation. En Silverlight, c'est manifestement différent. Du coup, tu me mets un énorme doute. Je travaille la question et je reviens vers vous.

David

Merci

[EmacLi]

Pour moi ça sera un MouseDoubleClick sur le DataGrid, la répercution du thème en cours sur un ChildWindow (SilverlightToolKit) et plus de thème !

[Golzinne]

Pour moi ça sera un MouseDoubleClick sur le DataGrid, la répercution du thème en cours sur un ChildWindow (SilverlightToolKit) et plus de thème !

Un mouseDoubleClick ça se simule très facilement...

[EmacLi]

Ah si autre chose,

Pouvoir accéder aux banques de certificats (équivalent de X509Store et X509Certificate2) et pouvoir faire de la signature électronique de documents (équivalent à SignedXml).

[wil4linux]

Hello,

As-tu jeté un oeil à WCF RIA Services pour Silverlight 4 ? Si non, je t'invite à regarder mes tutoriaux à ce sujet qui devraient répondre à une grosse partie de tes besoins : http://blogs.msdn.com/b/davrous/arch...e-de-code.aspx

Sinon, je pense que c'est une abberation de vouloir une connexion synchrone dans un contexte d'applications RIA. D'une manière plus générale, les tendances autour du cloud et la nécessité d'utiliser les processeurs multi-coeurs implique une programmation asynchrone. Pour résoudre cette complexité que tu indiques à juste titre, RIA Services propose quelques solutions en utilisant le binding de Silverlight et les ObservableCollection. Il existe d'autres approches récentes et intéressantes comme F# ou le Reactive Framework (RX). L'idée est de toutes ces approches est d'avoir un code à lecture séquentiel mais pourtant asynchrone.

David Rousset
Microsoft France
PS : moi aussi je sais des trucs sur Silverlight 5

Oui merci, depuis le temps j'ai pu me former un peu plus au Ria services. Il n'y a pas photo... la récupération des données est simpliste. Etant habitué au connexion synchrone (aspx ou winform) c'est un peu déroutant au début.

Là où j'ai trouvé des difficultés, c'est sur l'adaptation d'applications synchrone (aspx) vers du Silverlight, sans refondre les accès aux données et en essayant de simuler un modèle de communication synchrone via les RIA... L'application d'origine n'était pas orientée "service" donc un peu la galère.

donc voilà, ça va mieux maintenant

[chris81]

Une librairie ou un wcf permettant de faire de l'authentification OpenID et Oauth.

++

[davrous]

Merci

Hello,

Alors comme j'ai dit une grosse connerie, je suis parti me renseigner au près d'un alias interne de développeurs (sur WPF et Silverlight). En fait, ni l'un ni l'autre ne transforme le XAML en code IL à la compilation. En WPF, le XAML est transformé dans une forme binaire appelé BAML plus léger en taille et permettant ensuite au parser de gagner un peu en performance plus tard. Dans le cas de Silverlight, comme la runtime est plus légère que .NET, la solution de conserver le XAML en clair et de le compresser dans l'enveloppe ZIP du XAP leur suffisaient (aux développeurs de SL). En effet, le XAML se compresse particulièrement bien.

Ensuite, le XAML est parsé à l'exécution pour générer du code IL qui sera finalement exécuté.

J'ai posé ensuite la question suivante: serait-il alors intéressant de plutôt déclarer la partie UI en pur code-behind en C# par exemple plutôt qu'en XAML? La réponse fut non. Apparemment, l'équipe WPF avait essayé de générer le code-behind à partir du XAML à la compilation et ils avaient des performances inférieures au modèle actuellement retenu. Je n'ai pas eu davantage de réponses/détails sur ce sujet malgré tout.

A noter que le parser a été amélioré et revue dans la version 4 de Silverlight.

Bye,

David

[Thomas Lebrun]

En effet, le XAML se compresse particulièrement bien.

Car cela reste du texte

Dans la version WPF, il est convertit en BAML (Binary Application Markup Language) afin de gagner en performance lorsque le runtime y accède.

[Navedac]

Hello,

Alors comme j'ai dit une grosse connerie, je suis parti me renseigner au près d'un alias interne de développeurs (sur WPF et Silverlight). En fait, ni l'un ni l'autre ne transforme le XAML en code IL à la compilation. En WPF, le XAML est transformé dans une forme binaire appelé BAML plus léger en taille et permettant ensuite au parser de gagner un peu en performance plus tard. Dans le cas de Silverlight, comme la runtime est plus légère que .NET, la solution de conserver le XAML en clair et de le compresser dans l'enveloppe ZIP du XAP leur suffisaient (aux développeurs de SL). En effet, le XAML se compresse particulièrement bien.

Ensuite, le XAML est parsé à l'exécution pour générer du code IL qui sera finalement exécuté.

J'ai posé ensuite la question suivante: serait-il alors intéressant de plutôt déclarer la partie UI en pur code-behind en C# par exemple plutôt qu'en XAML? La réponse fut non. Apparemment, l'équipe WPF avait essayé de générer le code-behind à partir du XAML à la compilation et ils avaient des performances inférieures au modèle actuellement retenu. Je n'ai pas eu davantage de réponses/détails sur ce sujet malgré tout.

A noter que le parser a été amélioré et revue dans la version 4 de Silverlight.

Bye,

David

Bonjour

Peut être serait-il judicieux d'ouvir un post à part pour parler de la performance de Silverlight et du débat XAML pur ou code.
(On est loin du sujet de départ)
Le fonctionnement avec WPF étant différent de Silverlight, il ne faut pas faire de généralisation non plus.
Si vous ouvrez un autre post, je pourrais vous faire part de mes propres expérimentations sur le sujet. Je pense qu'elles feront débat

[Spaeda]

Salut,

Pour moi, ca serait effectivement bien d'améliorer le Debug du XAML et des Bindings.
Il faudrait aussi mettre en place le FindAncestor comme dans les Bindings WPF.
L'utilisation de Triggers à la place des VisualStates serait pas mal aussi.

[GuruuMeditation]

Comme dit, le binding.
Ajouter le TPL ce serait pas mal non plus.

[DotNET74]

Hello,

Non, c'est faux, le XAML est parsé et génère bien du code compilé (IL) à la fin. Donc, il n'y aucun intéret à ne pas passer par le XAML pour la description de l'interface en WPF ou Silverlight. Cela ne multiplie en rien la taille des XAP. Je ne sais pas d'où l'on sort tout cela !

Au final, que l'on code l'interface en "dur" en C# ou VB.NET ou en XAML, cela produit le même IL. Par contre, on revient à l'age de pierre si l'on code son interface en code-behind...

Bye,

David Rousset
Microsoft France

Bonjour,

désolé mais j'ai du mal à entendre/lire que Winform est l'âge de pierre !

aujourd'hui vous nous avez coller MVVM et pour C'EST l'antiprogrès, l'âge de pierre. Avec cette pattern il faut écrire 100 fois plus de code à la main dans un éditeur de l'âge de pierre (XAML) donc faut relativiser un peu.

C'était beaucoup plus conviviale et confortable en WinForm que maintenant. Tout ça pour des interfaces riches qui clignotent dans tout les sens.

Et je me marre encore plus depuis que j'ai mon WP7 Device sur lequel Microsoft à mis en place une interface dépourvu de tout icônes et effet de lumière !!!!

Mais bon ce n'est que mon avis