Mon monde en .NET - Commentaires

Extensibilité de WCF (1/3) - Thierry THOUA

Thierry THOUA — Fri, 27 May 2011 10:54:02 +0200

Il faut utiliser l'interface : IDispatchMessageInspector. Il est possible de voir le message avant l'envoi de celui-ci au client.

Extensibilité de WCF (1/3) - raimond

raimond — Tue, 24 May 2011 15:53:12 +0200

slut j'ai trouvé ton tuto très bien ? Moi j'ai envi de modifier les informations envoyée par le serveur avant qu'il ne soit renvoyer. si tu peux aider avec un petite implementation cela me fera plaisir( par exemple modification d'un fichier qui est generé par le serveur avant son envoie au client

merci

Hébergement d'un service WCF sans fichier .svc dans IIS et adaptation des options de binding - Thibaut David

Thibaut David — Mon, 28 Mar 2011 16:31:00 +0200

Bonjour,

merci pour cet article (et ceux à venir) permettant de mettre le doigt sur les multiples parties de WCF aussi puissantes que méconnues.
Je te propose d'ajouter un lien vers un article des MSDN expliquant la nouveauté des bindings par défaut de WCF 4 pour ceux qui désire aller plus loin sur ce sujet.
http://msdn.microsoft.com/en-us/lib...

bonne continuation.

Hébergement d'un service WCF sans fichier .svc dans IIS et adaptation des options de binding - SuperDamz

SuperDamz — Mon, 28 Feb 2011 12:43:00 +0100

Est-ce que ne pas avoir de fichier .svc est compatible avec le "Discover Services in Solution" de Visual Studio ?

Parce que sinon, ça n'apporte pas grand chose par rapport à ce qui existait déjà dans System.ServiceModel.Activation...

Gridview ASP.NET avec en source une collection d'elements "interface' - Pierre-Emmanuel Dautreppe

Pierre-Emmanuel Dautreppe — Wed, 14 Oct 2009 21:52:51 +0200

Et oui SuperDamz ! ICustomTypeDescriptor doit faire le boulot, mais il est "impensable" d'implémenter cette interface sur les types qui peuvent entrer dans la composition d'une liste.

D'ailleurs pour corriger ce que je disais plus haut, le ITypedList fait le boulot, mais uniquement dans un contexte WindowsForms. Cette interface est tout simplement ignorée dans le GridView.

Alors plusieurs autres possibilitées. L'exemple de la classe wrapper proposée ci-dessus est possible. Cependant j'en préfère une autre : ajouter un provider pour les objets de la collection. On peut en effet implémenter un TypeDescriptorProvider pour l'interface qui nous intéresse et faire des TypeDescriptor.AddProvider pour chacune des instances de la collection.

ATTENTION de ne pas faire ça sur les types concernées puisque cela pourrait avoir des conséquences sur le reste de l'application. Cependant sur les instances (si elles ont des durées de vie courtes - ce qui devrait être le cas lors du binding sur une grille), alors c'est tout à fait acceptable.

Qu'en pensez-vous ?

Gridview ASP.NET avec en source une collection d'elements "interface' - SuperDamz

SuperDamz — Mon, 12 Oct 2009 11:27:23 +0200

Salut,
Il me semble qu'en implémentant ICustomTypeDescriptor non pas sur la collection, mais sur le type des éléments, le tour sera joué.

Par contre, dans le cas du AutoGeneratesColumns, le Gridview utilise deux techniques différentes pour identifier le type des éléments :
- Si la collection possède une propriété Item[int], il va utiliser le type de cette propriété. C'est le cas des IList<T> mais ça marche aussi avec n'importe quoi d'autre (duck typing).
- Sinon, il va récupérer le premier élément de l'énumérable ; du coup, c'est son type concret qui est utilisé. Et cela, même si on est sur un IEnumerable<T>... Pas terrible en général, et même carrément gênant si la collection contient des dérivés différents de T.

Gridview ASP.NET avec en source une collection d'elements "interface' - Thierry Thoua

Thierry Thoua — Sun, 11 Oct 2009 23:39:55 +0200

Ouip ... Moi j'hésiterais. Je pense que j'envisagerais peut être la solution deux en reprenant l'idée du DataView .. Elle reçoit dans son constructeur une DataTable ... Ca pourrait très bien etre une CollectionView qui hériterait de ITypedList et recevrait dans le ctor la collection "couche basse". le CollectionView<T> utiliserait son "T" pour définir les propriétés visibles.

Gridview ASP.NET avec en source une collection d'elements "interface' - Pierre-Emmanuel Dautreppe

Pierre-Emmanuel Dautreppe — Sun, 11 Oct 2009 23:35:10 +0200

Effectivement, tu as besoin d'une classe "collection" custom qui fait le travail.
Je préfère cependant la première solution, surtout si tu as cette collection de base dans une couche framework. ça me semble logique qu'elle implémente cette fonctionnalité.

Gridview ASP.NET avec en source une collection d'elements "interface' - Thierry Thoua

Thierry Thoua — Sun, 11 Oct 2009 23:24:56 +0200

Le problème du ITypedList est qu'il necessite souvent la création d'une collection propre héritant de BindingList<T> ou de ObservableCollection<T> pour la représentation à l'UI ... Il n'est pas necessaire d'implémenter cet interface au niveau de l'api business.

Je récupère une facture ... je récupère pas du comportement lié au rendu quand je demande ma collection de facture client + fournisseur.

Dès lors, à mes yeux que ce soit ma solution (qui mélange déjà UI et business) ou ta seconde (qui est la plus propre à mes yeux) .. me semblent "propre". La mienne évite la consommation d'une classe en plus et la tienne (la seconde solution) offre la possibilité d'une séparation entre ce qui est "business" et ce qui est UI.

Gridview ASP.NET avec en source une collection d'elements "interface' - Pierre-Emmanuel Dautreppe

Pierre-Emmanuel Dautreppe — Sun, 11 Oct 2009 22:59:12 +0200

Oui bien sur !
C'est une solution, mais pas la bonne

Il faut savoir que c'est une limitation (connue) du GridView qui se base en effet sur les types concrets pour découvrir les valeurs des propriétés à afficher provenant d'une liste.

La vraie solution est de faire en sorte que la collection d'objets à binder implémente une simple interface nommée ITypedList. Cette interface possède deux seules méthodes. Une est totalement obsolète et était utilisée par le DataGrid. L'autre permet au GridView de connaître les types à afficher.

C'est à mon avis la solution la plus clean.
Pour cela, faire en sorte que l'application utilise une collection de base dans toute votre application et que cette collection fasse le boulot. Bref un vrai jeu d'enfant avec un petit framework dans votre application.

Ah oui, dernier point, cette interface est bien sûr implémentée par défaut dans les collections typées de notre propre framework

Autre façon de bypasser le mécanisme (plutôt que de modifier l'aspx de tous les gridview) est de créer une simple classe qui implémente ton interface et qui prend un seul paramètre dans ton constructeur : cette même interface. Toutes les méthodes / propriétés de ton interface vont simplement rediriger vers cette variable privée. Bref une encapsulation pour bypasser cette faiblesse.
On en reparle demain au stand up !

Balsamiq mockup ! ... le meilleur des wireframes ! - Thierry Thoua

Thierry Thoua — Sun, 02 Aug 2009 22:09:10 +0200

Un petit commentaire pour un lien dont j'ai oublié de parler (et pas envie de modifier mon post ...). Ce site vous offre des "UI contributions" d'utilisateurs ... vous pouvez egalement partager les votres : http://mockupstogo.net/

IsolatedStorageFile ! - Renaud Laloire

Renaud Laloire — Tue, 07 Jul 2009 23:41:00 +0200

Ne pas oublier cependant que l'acces a cet espace memoire (dont la taille est definie par l'application, donc par le developpeur) doit etre au prealable demande a l'utilisateur (client side) via une petite boite popup automatisee sans quoi rien ne pourra se faire.

Renaud

Merge rapide de colonnes d'une GridView en ASP.NET - SuperDamz

SuperDamz — Mon, 30 Mar 2009 13:23:18 +0200

Desolé DotClear vire les indentations :

private static void MergeColumn(GridView gv, int position)
{
var qSpawns = gv.Rows.Cast<TableRow>().GroupBy(row => row.Cells[position].Text).GetEnumerator();

for (int i = 0, nextSpan = 0; i < gv.Rows.Count; i++)
if (i == nextSpan && qSpawns.MoveNext())
nextSpan += gv.Rows[i].Cells[position].RowSpan = qSpawns.Current.Count();
else
gv.Rows[i].Cells.RemoveAt(position);
}

Evidement, il faut dès le départ que les colonnes soient sorties de telle manière que l'on puisse les grouper correctement.

I'm on twitter ! - Thibaut

Thibaut — Sun, 29 Mar 2009 17:07:45 +0200

Salut Thierry,

Alors t'as décidé d'écrire en anglais histoire de booster ton trafic :p

Sortie d'Internet Explorer 8 - Coupe_Kolonel

Coupe_Kolonel — Fri, 20 Mar 2009 13:28:55 +0100

Ben j'ai essayé sur ma machine (Dell Latitude D620, Windows XP, double écran), c'est chouette, assez ergonomique, mais encore un peu buggé : ça m'a flingué mon fond d'écran (wallpaper excentré, plus possibilité de le changer, etc). J'attends une version plus stable ! Mais ça me fera pas changer FF3...

News from the MIX 09 ! day 1 ! - Thibaut

Thibaut — Thu, 19 Mar 2009 10:10:11 +0100

Très intéressant tout cela !

Merci pour le compte rendu.

Wiki ASP.NET - Wiki

Wiki — Mon, 09 Mar 2009 20:24:26 +0100

et bien moi je suis fn de tes articles quoi qu'onbpuisse en dire ! lol

Création d'un système de notification en Ajax (microsoft) - Steve Degosserie

Steve Degosserie — Tue, 03 Mar 2009 09:31:14 +0100

Ze Titi is Back !!! ;o)

LINQ to SQL (detach / re attach dans un modèle N-tiers) - Thierry Thoua

Thierry Thoua — Wed, 25 Jun 2008 15:57:17 +0000

Il est indispensable d'utiliser des DTO .. ;). Après pour NHibernate, il y a la possibilité de "SaveOrUpdateCopy" ... Mais en effet, il est impossible d'utiliser la méthode Delete avec un objet détaché. Je suis néanmoins déçu de Entity Framework ... je m'attend à beaucoup plus d'un ORM ... (mais ca semble être le sentiment de beaucoup de personnes au vu de la lettre ouverte visible sur le net).

LINQ to SQL (detach / re attach dans un modèle N-tiers) - SuperDamz

SuperDamz — Wed, 25 Jun 2008 15:32:31 +0000

En effet la gestion de l'état peut poser problème... A moins de préciser quel est l'état à considérer comme "initial" lorsque l'on s'attache au nouveau contexte.
Table.Attach(TEntity entity, TEntity original)
Reste à déterminer l'original...