Où est le meilleur endroit pour mettre de style staticresources? J'ai mis les styles globaux et par défaut dans App.xaml et les styles spécifiques de la page dans la page_Name.xaml. Chaque contrôle doit-il avoir son propre style staticresource? Est-il acceptable de mettre des attributs de style directement dans le contrôle? J'ai une page avec 5 textes de texte dessus, si vous devriez y avoir un style pour chacun lorsque la seule différence est une largeur ou une propriété maxlength? Ou un style doit-il être défini avec les propriétés communes de chaque zone de texte et les propriétés de style spécifiques étant définies dans l'élément de contrôle?
4 Réponses :
Le projet Silverlight sur lequel je travaille sur Used Le modèle d'application Business RIA de MS. Il y avait tous leurs styles dans un dossier «actif» et le fichier s'appelait Styles.xaml. Je m'envoie à leur organisation et je l'aime, bien que j'ai également ajouté des dossiers séparés pour "dialogues" et personnalistes "contrôles".
Vous pouvez télécharger leur échantillon ici, ce qui peut répondre à vos questions: http://blogs.msdn.com/brada/archive/2009/07/10/amazing-business-apps-example-updated-for-silverlight-3- RTM-and-Net-Ria-Services-juillet-update.aspx
Désolé de brancher mes propres trucs (ou si cela n'est pas autorisé / fronça les sourcils à ce sujet), mais j'ai eu un rapide coup de bloguer à propos de mes expériences de réorganisation des ressources dans un grand projet Silverlight 2 (c.-à-d. Aucun projet de diffusion) un moment de retour. Post est ici .
J'accepterais votre dernière suggestion: placez la partie commune de toutes les boîtes de texte dans un dictionnaire de style, qui peut ensuite être chargée par l'application / la page / la commande, en fonction de ce que le niveau partage cette partie commune. La partie non commune devrait être définie directement dans les instances de zone de texte, il n'y a aucune utilité pour un autre style, à moins que vous ne réutilisiez ce paramètre spécial dans plusieurs textes de texte.
Je collectionne personnellement tous les styles "communs" (pour la zone de texte, la combinaison de Combobox, etc.) dans une seule ressource.xaml. Je sépare des styles dans des dictionnaires XAML-ressources supplémentaires que si je souhaiterais peut-être les exclure à des fins. Par exemple, je mets les styles pour les composants des fournisseurs tiers dans des fichiers de ressources séparés, s. Je peux charger mon fichier de ressources communs "autonome" dans des applications, qui ne font pas référence à ce 3e-Party-Lib. De même, je sépare des styles spécifiques au projet (couleurs adaptées à l'identité d'entreprise des clients) à partir de styles globaux (styles de produits indépendants du client), assez similaires aux directives qui devraient contenir pour héritage de classe. Mon application charge ensuite toutes les ressources, s.t. Les contrôles utilisateur n'ont pas besoin de savoir à leur sujet.
La hiérarchie existe pour une raison, c'est probablement une bonne idée de départ simple et local à un élément que vous travaillez avec , puis de la déplacer car il devient nécessaire.
Vos concepteurs peuvent également avoir des exigences particulières pouvant l'emporter. Par exemple, une équipe envoie de nombreuses révisions sur certains styles peut vouloir contenir tout le plan de style sur un fichier XAML unique jusqu'à ce qu'il soit prêt pour plus d'informations.
Les premiers articles sont vos styles "les plus cuits" et les styles utilisés les plus souvent utilisés, vous voudrez généralement commencer au fond et travailler votre chemin. Il est agréable de ne pas avoir à travailler avec plusieurs fichiers XAML, et conservez-le contenus.
Les styles de niveau d'application vont être utiles partout où votre application a son interface exposée, pour des éléments communs.
Si vous utilisez Silverlight 2, il s'agit de votre meilleure méthode non pack pour rendre vos styles accessibles dans votre application.
Soyez prudent Si vous utilisez régulièrement des ressources App.xaml, puisqu'une bibliothèque de test de l'unité qui vit en dehors de votre application sera beaucoup plus difficile à tester car elle ne prendra pas en charge les styles de niveau d'application de votre application dans certaines situations. < / p>
Dictionnaire fusionné
Les dictionnaires de ressources fusionnés Vous permettent de scinder vos styles en fichiers XAML supplémentaires, ce qui facilite la facilitant les facturer par zone de fonctionnalité, fonctionnalité, type de contrôle, nom d'équipe, etc. Découvrez cette fonctionnalité .
envisagez de l'utiliser pour les styles de niveau d'application dans des situations où il est logique, car vous pouvez ensuite les utiliser dans des projets et des solutions distincts.
non disponible pour Silverlight 2, cette fonctionnalité a été ajoutée à Silverlight 3.
niveau de page
Quelque chose de spécifique à une seule page (une application complète peut être une application visuelle, ou une partie d'une application) qui ne saigne pas au-delà des bords est un bon candidat pour cela.
N'hésitez pas à commencer plus loin l'arborescence visuelle (telle que le niveau de contrôle) et déplacez ces styles comme cela a du sens.
au panneau
C'est bien de contenir une bande de pièces similaires, comme lors du formatage d'un formulaire.
au contrôle
Commencez ici. Lorsque vous stortez un contrôle de mélange, cela commencera généralement ici, à moins que vous sélectionniez l'option de ressource à l'échelle de l'application.
Il s'agit de l'étape intermédiaire entre le réglage de la propriété et en réalité une ressource de style véritable, sinoiez simplement un setter pour la propriété de style du contrôle - mais vous pouvez facilement ajouter une clé X: et la déplacer dans le arbre visuel quand vous êtes prêt.
styles implicites et thèmes
Si votre équipe ou votre entreprise utilise un jeu de styles régulier pour tous les commandes d'un certain type (boutons, cochonsecks, vous le nommez), envisagez d'utiliser la fonctionnalité implicite du gestionnaire de style (une valeur ajoutée pour Silverlight) pour faire des styles implicites . Ceci est similaire à l'histoire de Styling WPF, où vous n'avez pas besoin de définir le style dans tous les endroits que vous l'utilisez.
J'ai trouvé un bon tutoriel en ligne avec une recherche rapide pour vous pour w.r.t. Votre question, si vous avez un ensemble de boîtes de texte lorsque les différences sont maxlength, largeur, etc., vous devez probablement définir les celles explicitement comme des propriétés sur chaque instance de contrôle - si elles sont différentes.
Une fois que vous avez quelques-unes (disons, 3, éléments) à l'aide des mêmes valeurs, il peut être judicieux de le retirer puis de commencer à utiliser un style = "{staticresource Name }" attribut . Si vous tapez XAML à la main, cependant, c'est beaucoup plus gênant que de taper la largeur = "20". Hiérarchie de style typique dans l'ordre inverse
Quand utiliser Propriétés au lieu de styles communs communs