Le getter de la mort

Nous utilisons très souvent des propriétés public sur des classes, que ce soit en get ou set. SharePoint et son SDK ni manque pas non plus. Cependant méfiez vous de certains pièges où on pense que le getter ne renvoi qu’une variable interne ! ce n’est pas toujours vrai ! Le getter peu faire beaucoup de chose avant de vous renvoyer le résultat… Les performances de votre application peuvent donc en pâtir, mais vous pouvez carrément avoir des “bugs”. Un bon exemple avec le SPWeb.RootFolder :

Scénario : Vous devez modifier la WelcomePage d’un SPWeb par code. Par défaut on aurait tendance à faire ça :

SPWeb w = ….. // je ne m’attarde pas sur la récupération du SPWeb

w.RootFolder.WelcomePage = “toto.aspx”

w.RootFolder.Update();

Comme beaucoup de classes dans le SDK de SharePoint, il faut appeler la méthode Update pour valider la mise à jour. Mais il se trouve que ça ne marche pas ! (pas de plantage mais la page d’accueil ne sera pas changée) pourquoi ? Regardons l’implémentation de RootFolder avec Reflector :

public SPFolder RootFolder { get { return new SPFolder(this, ""); } }

Et oui ! une nouvelle instance à chaque fois ! du coup l’appel à Update n’est pas fait sur la même instance de SPFolder et on perd donc la modification de la WelcomePage.

Solution  : Dans ce cas il faut faire ça :

SPFolder f = w.RootFolder;

f.WelcomePage = “toto.aspx”

f.Update();

Et le tour est joué !

Conclusion : ne soyons pas trop flemmard à déclarer des variables intermédiaires…

Tagués avec : , , , , , , , ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Verifions que vous êtes un humain * Time limit is exhausted. Please reload CAPTCHA.