Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

Build 2014 : .NET : Le grand retour !

[new:30/04/2014]Est-ce la bonne influence de Scott Guthrie nommé Executive Vice President par Nadella dont je parlais dans le dernier billet ? Peu importe car finalement ce qui compte c’est qu’après les délires monomaniaques autour de WinRT de Ballmer et Sinofsky, l’ère Nadella s’annonce plus ouverte, plus pragmatique, et c’est une bonne chose. En premier pour .NET …

imagePlus...

Stratégie de développement Cross-Platform–Partie 1

[new:31/12/2012]Développer cette année c’est forcément développer cross-plateforme. Mieux, c’est développer cross-form factor... Android, iOS, Windows 7, Windows 8, sur PC, tablette, smartphone... Un vrai casse-tête qui peut couter une fortune si on n’adopte pas dès le départ la bonne stratégie et les bons outils. C’est une stratégie opérationnelle avec ses outils que je vais vous présenter dans cette série de billets dont voici la première partie.Plus...

Silverlight : accéder à l’IP du client (version 2)

[new:30/06/2011]Accéder à l’IP du client est parfois nécessaire, Silverlight étant une technologie côté client tournant dans une sandbox cette information ne lui est pas accessible. Dans un précédent billet je vous ai montré la façon classique, via un service Web, d’obtenir l’IP du client. Aujourd’hui je vous propose une astuce d’un style très différent.Plus...

Quand browsers et proxies jouent à cache-cache avec vos Xap...

[new:30/06/2011]Lorsqu’on travaille avec Silverlight on peut facilement devenir fou à cause d’un proxy ou d’un browser dont le cache est mal géré. En vous resservant un vieux Xap sans vous le dire, vous avez l’impression que votre session de debug ne sert à rien ou bien vos utilisateurs vous décrivent des bugs pourtant réglés depuis un moment... Dans tous les cas un proxy (ou un browser) est en train de jouer à cache-cache avec vos Xap et vos nerfs !Plus...

Mieux utiliser les "Master Page" de ASP.NET

Quelle belle invention que les pages maîtres (Master Page) introduites sous ASP.NET 2.0 ! Quand on pense aux contorsions nécessaires pour avoir un menu ou des bandeaux lattéraux sans cet ajout décisif, et pire quand on sait comment il fallait faire ( et qu'il faut encore faire) sous d'autres environnements...

Bref les pages maître c'est super. Mais voilà, il arrive que les pages de contenu doivent accéder à des champs de la page maître, soit pour y lire certaines informations, soit pour en écrire (cas d'un label d'info se trouvant sur une MP dont le contenu est changé par la page courante par exemple).

La (mauvaise) méthode habituelle 

Prenons l'exemple du label (que vous remplacerez mentalement par ce que vous voulez du moment qu'il s'agit d'un objet de la MP). On rencontre très souvent un code qui ressemble à cela dans les pages détails :

Label info = this.Master.Page.FindControl("labelInfo") as Label;
if (info != null) { info.Text = "information sur la page en cours..."; }

 Et encore, le test sur le null est plutôt un luxe qui ne se voit pas dans tous les codes !

Bien entendu cette méthode fonctionne, mais elle n'est franchement pas propre. Au moins pour une raison, c'est qu'une simple erreur de frappe dans le FindControl et c'est le bug, pas trop grave si le test sur null est ajouté comme dans l'exemple de code ci-dessus, mais bug quand même. En aucun cas le compilateur ne peut détecter l'erreur. Dommage pour un environnement fortement typé !

Mais ne riez pas trop vite, on rencontre des horreurs bien pire que le code montré ici : certains n'hésitent pas à transtyper la propriété this.Master.Page pour accéder directement à l'objet ! Et comme un mauvais chemin ne peut mener qu'à faire des âneries de plus en plus grosses, les éléments d'interface étant protected par défaut, pour que ça passe (en force!) les mêmes sont donc contraints de modifier la visibilité de l'objet convoité en le faisant passer en public. Dire que c'est du bricolage est très largement en dessous de la réalité.

Heureusement il existe une solution très simple qui marche et qui permet d'écrire un code de bien meilleur qualité, c'est la directive MasterType, trop peu connue et encore moins utilisée (il y a même des pervers qui en ont entendu parlé mais qui ne s'en servent pas, si, ça existe!).

La (bonne) méthode à utiliser

Elle se décompose en deux temps :

  • Temps 1 : Créer des propriétés dans la page maître
  • Temps 2 : utiliser la directive MasterType

La propriété 

Continuons sur notre exemple du label, il conviendra alors d'écrire quelque chose du genre (dans le code de la page maître donc) :

 public Label InfoLabel { get { return labelInfo; } }

Honnêtement il y a encore mieux à faire, personnellement je n'aime pas voir des objets exposés de la sorte. On créera plutôt une propriété de ce type :

public string Info { get { return labelInfo.Text; } set { labelInfo.Text=value;} }

Chacun ses préférences et ses justifications, nous venons en tout cas de répondre à la première exigence pour faire un code plus propre.

La directive

Dans le fichier .aspx de la page de contenu, il suffit d'ajouter la directive suivante :

<%@ MasterType VirtualPath="~/blabla/LaMasterPageDeMonSite.master" %>

Cette simple directement va instruire l'environnement du vrai type de la page master, et, Ô magie !, c'est la propriété this.Master qui est automatiquement typée correctement !

On peut dès lors reprendre le même code que celui proposé en introduction (celui utilisant FindControl) et le réécrire proprement en bénéficiant d'un typage fort et de tous les contrôles dignes d'un environnement comme ASP.NET :

this.Master.InfoLabel.Text = "info affiché sur la page maître";

On suppose ici avoir utiliser la méthode consistant à publier le label via une propriété. Avec la seconde méthode proposée, encore plus propre, le code sera encore plus simple et lisible :

this.Master.Info = "info affiché sur la page maître";

Conclusion

C'est pas plus joli comme ça ? ! Si, forcément...

Alors maintenant que vous savez que MasterType existe, n'hésitez pas à vous en servir... et ...

Stay Tuned !