• Comment fonctionne un HttpHandler?
• Pourquoi ne pas utiliser les UpdatePanels?
• A quoi sert un MembershipProvider et comment s’en servir?

Si ces questions vous paressent obscures et que vous êtes plutôt un développeur “glisser-déposer”, alors je vous propose de vous “glisser-déposer” sur un autre blog

Pour les autres, j’ai un aveu à vous faire: je viens de découvrir qu’il n’est pas possible d’afficher 2 pages ASP.Net en simultané si elles accèdent à la Session.

J’ai cru que j’étais sous l’effet d’une drogue… mais non, c’était bien vrai.
J’ai alors voulu en avoir le cœur net, et j’ai fouillé de nombreux forums… c’est la que j’ai découvert que d’autres l’on découvert après 5 ans d’expériences en ASP.Net!!!

Certes, on ouvre rarement 2 pages Web d’un même site, mais il est plus fréquent d’avoir 2 appelles Ajax en simultané.
C’est mon cas, car j’aime Ajax, j’aime le Web, et j’utilise une technique “Comet” appelé “Long Pooling”. Cela consiste à faire un appelle Ajax potentiellement infinie, qui va se terminé seulement si le serveur à quelque chose à nous dire. Cela permet d’avoir un système de notification très simple à implémenter.

Pour vulgariser, au lieu d’avoir ça:

Client: “Tu veux me dire quelque chose?”
Server: “Non”
Client: “Tu veux me dire quelque chose?”
Server: “Non”
Client: “Tu veux me dire quelque chose?”
Server: “Mais lâche moi sale client!!!”

En long polling ça donne ça:

Client: “Bon, tu me préviens si t’as un truc à me dire…”
Server: “…”
Server: “…”
Server: “…”
Server: “…”
Server: “… ouai, j’ai un truc pour toi, un nouveau message”
Client: “OK, je le traite, bon, tu me préviens si t’as un autre truc à me dire…”

Et sinon, en C# ça donne ça:

public string LongAjaxCall()
{
    string result = null

    while(result == null)
    {
        lock(this.notificationList)
        {
            if(notificationList.Count > 0)
            {
                result = new JavaScriptSerializer().Serialize(this.notificationList.ToArray());
                this.notificationList.Clear();
            }
        }
        if(result == null)
            Thread.Sleep(500);
    }
}

En général, le serveur n’a pas les mêmes choses à dire aux différents clients, c’est pourquoi on utilise la Session. Mais cette dernière est verrouillée par le long pooling, l’utilisateur ne sera alors pas en mesure d’ouvrir une nouvelle page si l’appelle Ajax ne se termine pas, ce qui est plutôt fâcheux.

Et Spring.Net dans tout ça?

J’utilise massivement Spring.net, pas seulement pour l’IOC, mais pour bien d’autres choses que ce merveilleux framework offre.
Dans le cadre d’une application Web, il est possible d’avoir un “scope” pour les instances des objets:

• application: un singleton pour toute l’application Web
• session: l’instance n’existe que dans le cadre d’une session ASP.Net
• request: l’instance n’existe pour pour la duré de la requête HTTP

J’utilise pas mal le scope “Session”, afin d’instancier des “contrôleurs” différents pour chaque utilisateurs. Je peux ainsi conserver un état à l’aide des membres de mes contrôleurs (ou conserver une connexion SQL, etc.).

Je vous propose alors de jeter un œil à mon exemple afin de comprendre mon problème: http://bitbucket.org/grozeille/testaspsessionmultithread/src
Cette solution contient un premier exemple “TestASPSessionMultithread.Bad” qui illustre mon problème.

L’exemple est simple:
Vous avez une première page “Default.aspx” qui permet d’ajouter une “string” à une liste à l’aide du button “add” qui effectuera un appelle Ajax.
Vous pouvez alors ensuite déclencher un “long pooling” à partir du boutton “long polling” qui va demander au serveur de renvoyer les nouveaux items.

Dans cet ordre, tout va bien. Par contre, si vous faite un “long pooling” en premier, le boutton “add” restera bloqué et il sera donc impossible d’ajouter un nouvel item.

De même, vous pouvez tester aussi la page “Other.aspx” qui simule un lourd traitement qui prend 5 secondes. Quand vous essayer d’ouvrir la page “Other” et que vous tentez de recharger la page “Default” en parallèle, cette dernière va attendre la fin du chargement de la page “Other”.

A noter aussi que j’affiche le “creation time” des différents contrôleurs. Puisque Spring.Net permet d’avoir du LazyLoad, on voit que le OtherController est créé après le DefaultController.

Si vous regardez le code en détail, vous pouvez voir que je gère les appelles Ajax à l’aide d’un HttpHandler custom.
Je pense que le code est suffisamment bien commenté pour le comprendre, et pour ceux qui ont la flemme de récupérer le source depuis BitBucket, voici l’extrait:

public class BadAjaxHttpHandler : IHttpHandler, IRequiresSessionState
{
    public void ProcessRequest(HttpContext context)
    {
        // get the name of the controller and the action from the URL
        var action = context.Request.Url.Segments[context.Request.Url.Segments.Length - 1];
        var controller = context.Request.Url.Segments[context.Request.Url.Segments.Length - 2]
            .Replace(".ajax", string.Empty)
            .Replace("/", string.Empty);

        // get the instance of the controller thanks to its name
        var instance = ContextRegistry.GetContext().GetObject(controller);

        // get the method of the controller thanks to reflection
        var method = instance.GetType().GetMethod(action, BindingFlags.Instance | BindingFlags.Public);
        var args = new List();
        foreach (var item in method.GetParameters())
        {
            args.Add(TypeDescriptor.GetConverter(item.ParameterType).ConvertFromString(context.Request.Params[item.Name]));
        }

        // invoke the method of the controller
        var result = method.Invoke(instance, args.ToArray());

        // return the JSON value of the method result
        context.Response.Write(new JavaScriptSerializer().Serialize(result));
        context.Response.StatusCode = 200;
        context.Response.End();

On remarque que pour accéder à la session nous avons ici besoin d’implémenter l’interface “IRequiresSessionState”, mais la aussi, comme c’est en lecture/écriture, cela verrouille la session le temps de la requête HTTP.

Comment résoudre le problème?

La solution est dans le projet “02-TestASPSessionMultithread.Good.Unsecured”.

Pourquoi “Unsecured” ? On verra ça plus tard.

La solution est simple, il suffit d’accéder à la Session en “lecture seule”.
En effet, il peut être problématique d’ajouter une même clé depuis 2 thread concurrents, mais une fois que la clé est créée, c’est à vous de gérer la concurrence de la valeur.

Exemple:

Session[“list”] = new List(); // problème de concurrence, donc session verrouillée

((List)Session[“list”]).Add(“toto”); // ce cas est une lecture seule de la session, mais à vous de gérer la concurrence pour la collection

Comme Spring.Net est en quelque sorte une “grosse collection d’instance”, et que Sprint.net utilise une seule clé “spring.object”, cela s’applique aussi

Par défaut, les pages sont en accès Write à la session. Pour changer cela, il faut ajouter une option dans l’ASPX:

<%@ Page EnableSessionState="ReadOnly"  %>

Il a fallut un petit changement dans le HttpHandler Ajax aussi:

public class AjaxHttpHandler : IHttpHandler, IReadOnlySessionState

Cette nouvelle interface “IReadOnlySessionState” parle d’elle même

Et voila! C’est tout! Ca marche, plus de problème de concurrence!
Enfin… non ce n’est pas tout, on a un petit problème, c’est que Sprint.net ne pourra plus jamais initialiser la session sans accès en écriture
Il faut donc trouver un “bootstrap” qui accède à la session en écriture juste le temps de créer le contexte Spring.Net.

L’astuce est donc de faire une redirection vers un HttpHandler particulier “SpringSessionHttpHandler” si la session est nouvelle. Il peut alors accèder à la session en écriture grâce à l’interface “IRequiresSessionState” pour initialiser le contexte et rediriger vers la page d’origine.

Ceci est fait lors du “OnLoad” car nos pages héritent de “SessionPage”.

public class SessionPage : Page
{
    protected override void OnLoad(EventArgs e)
    {
        // build the spring.net session
        if (Session.IsNewSession)
        Response.Redirect("SpringSessionHttpHandler?ReturnUrl=" + Server.UrlEncode(Request.Url.ToString()), true);

        base.OnLoad(e);
    }
}

Le code du HttpHandler est très simple: il force la création du contexte Spring dans la session, puis redirige sur la page d’origine qui elle a un accès en lecture seule sur la session.

public class BadAjaxHttpHandler : IHttpHandler, IRequiresSessionState
    {
        public void ProcessRequest(HttpContext context)
        {
            // get the name of the controller and the action from the URL
            var action = context.Request.Url.Segments[context.Request.Url.Segments.Length - 1];
            var controller = context.Request.Url.Segments[context.Request.Url.Segments.Length - 2]
                .Replace(".ajax", string.Empty)
                .Replace("/", string.Empty);

            // get the instance of the controller thanks to its name
            var instance = ContextRegistry.GetContext().GetObject(controller);

            // get the method of the controller thanks to reflection
            var method = instance.GetType().GetMethod(action, BindingFlags.Instance | BindingFlags.Public);
            var args = new List<object>();
            foreach (var item in method.GetParameters())
            {
                args.Add(TypeDescriptor.GetConverter(item.ParameterType).ConvertFromString(context.Request.Params[item.Name]));
            }

            // invoke the method of the controller
            var result = method.Invoke(instance, args.ToArray());

            // return the JSON value of the method result
            context.Response.Write(new JavaScriptSerializer().Serialize(result));
            context.Response.StatusCode = 200;
            context.Response.End();
        }

Mais quel astuce géniale! …mais pourquoi “Unsecured” ?

Vous pouvez remarquer que j’affiche l’ID de la session dans la page.
L’identifiant de session est stocké par défaut dans un cookie. J’ai tout de même changé le nom de ce dernier, car si je laisse la valeur par défaut, je risque d’avoir un conflit avec une autre application (erreur de débutant)

<sessionState cookieName="TestSession"/>

Normalement, le cookie est “sécurisé”, cad qu’il n’est pas accessible depuis du Javascript malicieux.
Mais bon, un cookie ça reste quand même pas super sécurisé.

Si vous voulez tester un vol de session, il vous suffit de copier/coller l’ID de la session dans un cookie d’un autre navigateur.

Comment faire alors pour sécuriser le tout? Vous avez pour cela différentes solutions:

• implémenter votre propre gestion d’ID de session avec <sessionState customProvider=”MonType”>, et vérifier l’identité à l’aide de critère comme l’IP du client
• coupler la session avec l’authentification

C’est cette dernière solution que je vais vous présenter, car c’est la plus simple.
L’authentification en ASP.Net se fait à l’aide du MembershipProvider, que vous pouvez implémenter vous même. Le framework .Net va alors gérer l’identité à l’aide d’un cookie aussi, mais ce dernier est beaucoup plus sécurisé et vous pouvez y faire confiance.
Je vais alors stocker dans la session la valeur du cookie d’authentification, et vérifier donc l’identité avant d’accéder à la session.

Vous pouvez vérifiez cela par vous même à l’aide du projet 03-TestASPSessionMultithread.Good.Secured
Si vous tentez de voler le cookie d’authentification pour l’utiliser sur un autre navigateur, vous serez alors déconnecté. Si vous tentez de voler le cookie de session, vous serez alors aussi déconnecté.

Les pages hérites alors de “SecuredSessionPage”, et vont alors vérifier le cookie de session dans le “OnLoad“:

// if the user tried to steal the session of another user
if (Page.Request.Cookies[FormsAuthentication.FormsCookieName] == null ||
    !Equals(Page.Request.Cookies[FormsAuthentication.FormsCookieName].Value, Session[FormsAuthentication.FormsCookieName]))
{
    this.Logout();
}

Je vous laisse ensuite découvrir l’implémentation de l’authentification, mais ce n’est pas le sujet de ce billet et il n’y a rien de plus classique.

Conclusion

Si comme moi vous utiliser Spring.net avec ASP.net et que vous avez des problèmes de lenteur, essayer cette astuce

C’était hier, dans les locaux de Zenika: http://www.eventbrite.com/event/727568176

Mais comme vous êtes nombreux à ne pas avoir pu y assister, et que certains d’entre vous souhaites consulter les sources des démos, je vous proposes de télécharger le tout sur mon Bitbucket: http://bitbucket.org/grozeille/spring.demo/src

J’espère que ça vous a plus, et que cela vous a permis de découvrir de nouvelles choses dans Spring.Net.
Si des gens d’ALT.Net  souhaite que je refasse la présentation à une date moins problématique, n’hésitez par à me le faire savoir.
De même, si vous souhaitez que j’approfondisse un sujet en prenant plus de temps à expliquer les démos, ce serait avec plaisir.

Spring est devenu un framework “standard de facto” dans le monde Java. Il inclut bien plus que de l’IOC: AOP, Web MVC, etc.
Aujourd’hui, Spring c’est aussi un serveur “JEE” d’un nouveau genre. Puis il y a eu l’acquisition d’Hyperic, puis c’est au tour de VMWare d’acquérir Spring…
Bref, c’est une vrai success story dans le monde Java.

Quand à Spring.Net, ce n’est pas encore ça. Le projet Castle est même lui plus avancé: framework IOC, AOP, Web MVC, etc.
Je crois que Castle était en avance sur son temps dans l’écosystème .Net, c’est peut-être la raison pourquoi il n’a pas pris la même ampleur que Spring Java.

Mais j’ai foie en Spring! Ce framework m’aide tout les jours à réaliser des applications d’entreprises complexes et robustes.

Mais une chose rebute TOUT développeur .Net: la configuration XML.
Le XML c’est verbeux, le XML ça ne se compile pas, on n’a pas intellisense avec le XML…
Bref, plein de raison de préférer des frameworks comme AutoFac ou Ninject qui propose une approche de configuration par code, voir à la sauce “fluent”.

A ça, je réponds que:

• la verbosité n’est pas dramatique quand on a la complétion. Je remarque aussi que la verbosité est reproché avec des fichiers XML de 1000 lignes… ce qui est tout aussi vrai avec un code source C# de 1000 lignes.
• la complétion et la vérification du XML peut être faite à l’édition ou la compilation, c’est ce que fait  Spring IDE sous Eclipse, mais pas de support VisualStudio pour le moment (même si Resharper arrive à la rescousse)
• on PEUT faire du Spring sans XML, même si les gens de Spring.Net n’ont pas été très cool sur l’API…

Comme l’API de Spring.Net est un peut obscure et pas très documenté sur son utilisation en dehors d’une configuration XML, j’ai décidé de faire une petite surcouche pour facilité l’écriture et que ce soit suffisamment intuitif pour ne pas avoir besoin d’une doc.

De cette volonté est né le projet Spring.Fluent!!

C’est un projet OpenSource, ce qui veut dire que je ne vous interdit pas de m’aider à réaliser mon rêve
Ceci-dit, un projet similaire existe déjà: http://code.google.com/p/fluent-spring/
Alors pourquoi faire un fork? Car il m’a fallut 1 journée pour faire autant et même plus que ce le projet propose, et à ma façon qui me plait rien qu’à moi!

De plus, Mark Pollack à l’annonce de Spring.Net 1.3, a prétendu que la configuration “par code Fluent” sera un point de la prochaine version, à savoir la 2.0: http://www.infoq.com/interviews/Spring.NET-1.3-2.0

Je souhaite à Mark et toutes l’équipe de Spring.Net de réussir, en attendant j’ai ma propre solution. Et si elle peut les inspirer pour Spring.Net 2.0, ce sera formidable. C’est pourquoi je pense ce cet “effort” n’est pas perdu: il n’est jamais inutile de contribuer au monde OpenSource et à faire connaitre ses opinions.

Il existe un autre standard : les applications .Net possède un fichier “mon_application.exe.config” qui n’est autre qu’un XML contenant le paramétrage de l’appliation. Ce fichier est structuré en 2 grosses parties: l’entête avec la section “configSections” qui décrit les sections du XML et les “parser” qui vont lire ces dernières. Puis il y a les sections proprement dites.

Quand on veut utiliser des settings de l’application de type “clef=valeur”, on peut les renseigner dans la section “applicationSettings”. On peut ainsi facilement créer un paramétrage de l’application mais aussi pour chaque utilisateur à l’aide de la section “userSettings”.
Voici un exemple de paramétrage:

<userSettings>
	<MonApp.Settings>
		<setting name="PreferredLanguage" serializeAs="String">
			<value>fr-FR</value>
		</setting>
	</MonApp.Settings>
</userSettings>
<applicationSettings>
	<MonApp.Settings>
		<setting name="TimeShowMsg" serializeAs="String">
			<value>5</value>
		</setting>
		<setting name="NotepadPath" serializeAs="String">
			<value>c:\windows\notepad.exe</value>
		</setting>
	</MonApp.Settings>
</applicationSettings>

VisualStudio propose une technique simple pour manipuler ces paramétrage. Il permet de créer un fichier “.settings” qui va tout simplement générer une classe pour accéder à tout ça, et qui va aussi permettre de sauvegarder les settings de l’utilisateur courant (dans un .config séparé dans C:\Documents and Settings\UserName\Local Settings\AppName\).

// on récupère la valeur d'une clef très simplement
String value = Settings.Default.MyKey;
// si elle a comme scope "user", on peut la modifier et la sauvegarder
Settings.Default.MyKey= value;
Settings.Default.Save();

Pour ma part, j’utilise massivement Spring.net et ses XML. Mes objets possèdent souvent des attributs qui ressemble à des paramètres (j’externalise au maximum). De plus, Spring.net propose de référencer d’autre XML, ce qui me permet de découper mon paramétrage en plusieurs fichiers pour différent domaine (Logging, Base de données, etc).

<!-- dans le App.config -->
<objects xmlns="http://www.springframework.net">
  <import resource="logging.xml"/>
  <import resource="database.xml"/>;
  <import resource="general.xml"/>
</objects>

<!-- dans general.xml -->
<objects xmlns="http://www.springframework.net">
  <object id="Setting" type="MonApp.Setting, MonApp">
    <property name="Timeout" value="100"/>
  </object>
</objects>

Une des solutions les plus élégante pour un public informaticien, est de créer ses propres balises XML Spring.net, comme celles déjà existantes (Exemple: paramétrage de base de données.) On masque ainsi la complexité de la construction du programme en laissant une grande souplesse. Mais cette solution demande un certain effort dans la réalisation du parser XML.

<objects xmlns='http://www.springframework.net'
             xmlns:custom="http://www.grozeillle.com/custom">
  <custom:Setting timeout="100">
    <custom:EmbededSetting name="Default">
      <!-- autres settings -->
    </custom:EmbededSetting/>
  </custom:Setting>
</objects>

<objects xmlns='http://www.springframework.net'>
<!-- Cet objet contient une liste de "fournisseur" de paramétres-->
  <object type="Spring.Objects.Factory.Config.VariablePlaceholderConfigurer, Spring.Core">
	<property name="VariableSources">
	  <list>
		<!-- Nous n'avons ici qu'un seul fournisseur, 
			qui va chercher les paramétrages dans un fichier .properties -->
		<object type="Spring.Objects.Factory.Config.PropertyFileVariableSource, Spring.Core">
		  <!- la liste de nos fichiers .properties -->
		  <property name="Locations">
			<list>
			  <value>config.properties</value>
			</list>
		  </property>
		</object>
	  </list>
	</property>
  </object>
</objects>

On peut ainsi utiliser des variables comme ceci:

<objects xmlns='http://www.springframework.net'>
	<!-- mon object de type "MyTutoClass" a besoin du chemin de Notepad.exe -->
	<object type="MyApp.MyTutoClass, MyApp">
		<property name="NotepadPath" value="${notepad.path}">
	</object>
</objects>

Mon fichier .properties ressemble simplement à ça:

;ceci est un commentaire
notepad.path=c:\windows\notepad.exe

Spring.net propose plusieurs méthodes de recherche de ces clef+valeur. On peut avoir comme source des fichiers “.properties”, mais aussi la section “settings” dans l’App.config (comme vu plus haut), la base de Registre, etc. Voici la liste dans la documentation officiel. Si elle ne vous suffit pas, vous pouvez toujours créer votre “provider” vous même.

Enfin, pour les plus “hardcore” d’entre-vous (ceux qui aime recoder l’univers), vous pouvez aussi créer votre propre XML avec votre propre format. Il est vrai qu’on souhaite parfois faire sa propre classe “Setting” car on veut hiérarchiser les différents paramètres. Admettons que l’on veuille vraiment avoir son propre format de fichier XML, ceci reste très simple en .Net:

// créer un "serializer" de Setting
XmlSerializer serializer = new XmlSerializer(typeof(Setting));
// création d'un flux sur mon fichier XML
TextWriter writer = new StreamWriter("Settings.xml");
// création de ma classe de Setting
Setting setting = new Setting();
// setting.Timeout = 5; etc, etc..
// enfin, sauvegarde de mon objet sous format XML dans le flux de mon fichier "Settings.xml"
serializer.Serialize(writer, setting);

On ne peut pas faire plus simple, non? Et vous savez quoi? Par défaut, ça marche sans rien faire d’autre. Mais si vous voulez customizer le format du XML, il suffira de décorer notre classe Setting à l’aide de quelques attributs [XmlAttribute]. Si vous voulez générer un schéma XSD de ce format XML, c’est à l’aide de c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\xsd.exe.

Pour conserver une trace de mon incompétence, voici donc la solution:
Pour qu’on puisse dialoguer avec un service WCF dans une page Asp.net, je leur injecte un proxy à l’aide de Spring (voir Spring.net pour le web). Pour cela, j’utilise une “factory de proxy” à l’aide de l’interface IFactoryObject.
Crédule que j’étais, j’imaginais que le fait de retourner true pour la propriété IsSingleton allait faire en sorte que Spring.net ne fasse appel qu’une seule fois à la méthode GetObject().
Et bien non ! C’est à vous d’être cohérent: même si IsSingleton retourne true, rien ne vous empêche de toujours retourner une instance différente dans la méthode GetObject().

Pour en revenir à mon problème, vous l’aurez compris : ma méthode GetObject() retournait à chaque fois un nouveau proxy vers le service WCF.
Résulat : à chaque fois que Spring avait besoin d’injecter mon proxy à une page (postback par exemple), je créai une nouvelle connexion au serveur WCF. J’ai fini par atteindre le nombre de connexion max, et le serveur ne répondait plus.

Il est tout de même dommage que les traces WCF ne m’ont pas révélé d’exception expliquant cette limite max de connexion

Pour approfondir le sujet sur les IFactoryObject :
Un objet qui implémente IFactoryObject doit toujours être un singleton, si ce n’est pas le cas on obtient une exception:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" singleton="false"/>

La propriété IsSingleton de la factory indique seulement ce qu’elle est censée faire… mais sans aucune obligation/vérification du comportement. Dans mon cas, je retournais true mais rien ne m’a empêché de créer une nouvelle instance à chaque appel…

Dans le cas particulier d’une application Asp.net, on peut avoir des “presque singleton” en changeant le scope:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" scope="application"/>

• scope=”application” : c’est un singleton de toute l’application web. Firefox et Safari m’affiche toujours 1.
• scope=”session” : c’est un singleton pour chaque session cliente. Firefox et Safari m’affiche toujours 2 (1 instance pour Firefox + 1 instance pour Safari).
• scope=”request” : c’est un singleton dans le cadre de la requête. Firefox et Safari vois le compteur s’incrémenter à chaque rafraichissement de la page.

Pour plus d’infos sur les scopes.

Conclusion(s) :

1. Ce n’est pas la propriété IsSingleton qui détermine si Spring va faire appelle une ou plusieurs fois à votre Factory. C’est à elle de fournir le comportement adéquat.
2. Un singleton n’en est pas toujours un… ça dépend du contexte. Dans tous les cas, pour éviter les erreurs comme la mienne, n’oublier pas d’utiliser la destroyMethod pour libérer les ressources. (l’interface ILifeCycle de Java n’existe pas encore dans Spring.net mais la 1.2 sort en RC1 début mai…).
3. Un “Timeout” peut vouloir dire “trop de connexion au serveur”
4. Cette fameuse Factory de proxy WCF sera fournie dans Spring.net 1.2. j’aurais perdu moins de temps en prenant les sources des nightbuilds… vive l’OpenSource!

Si cette personne doit recompiler l’application pour voir le fruit de son travail, ce n’est pas très pratique voir impossible: allez lui expliquer que VisualStudio n’est pas nécessaire et qu’il est possible de créer des ressources avec ResGen.exe (et al.exe pour faire des assembly satellites). Très franchement, les traducteurs ne veulent pas de quelque chose d’aussi et vont vous fuir comme la peste si vous leur demander d’être des développeurs.

La solution est donc d’utiliser simplement des fichier *.resx sans les compiler, et elle a plusieurs avantages:

• le traducteur n’a pas à savoir comment compiler des ressources (ce n’est pas un développeur)
• les fichiers *.resx sont sous la forme XML, et donc (très?) lisible (la structure propose même un champ “commentaire”)
• il existe bien sûr des éditeurs de fichiers *.resx pour ceux qui ne veulent même pas savoir ce que XML veut dire: Resourcer for .net

Vous pouvez retrouver ces explication sur le blog suivant.
Et Oh joie! Ce blog explique comment réaliser un ResourceManager personnalisé capable de charger des fichiers .resx! C’est donc tous ce qu’il nous faut, nul besoin de réinventer un autre mécanisme de traduction maison.

Pour pousser la réflexion plus loin, je voulais utiliser Spring.net pour obtenir la traduction. Cette solution à pour avantage de ne passer que par le contexte pour obtenir cette dernière, peut importe dans quel fichier elle se trouve. Il suffit alors de paramétrer dans le fichier App.Config le chemin de chaque fichier *.resx.

Pour ce faire, rien de plus facile: Spring.net fournit une classe qui recense un certain nombre de ResourceManager. En référençant donc notre ResxResourceManager qui pointe sur notre fichier *.resx, le contexte Spring sera alors capable de fournir les bonnes traductions si on l’interroge. Pour obtenir une traduction dans la culture courante, il suffira alors d’écrire ceci:

ContextRegistry.GetContext().GetMessage("MaClef");

<object name="messageSource" type="Spring.Context.Support.ResourceSetMessageSource, Spring.Core">
  <property name="ResourceManagers">
    <list>
      <!-- ResourceManager qui pointe sur notre fichier Resx\MyResource.resx -->
      <object id="MyResource" type="TestWinformsRessources.ResxResourceManager">
        <constructor-arg name="baseName" value="MyResource"/>
        <constructor-arg name="resourceDir" value="Resx"/>
      </object>
    </list>
  </property>
</object>