Manuel de formation pour apprendre le langage Visual Studio [Eng]
...
Quelles sont les extensions?
Les extensions fournissent des fonctionnalités supplémentaires qui ne sont pas standard dans le produit. Une façon de penser à eux est comme des add-ons. Les extensions peuvent être utilisées pour interagir directement avec l'utilisateur, ou pour effectuer un travail derrière l'interface utilisateur, tel que l'accès aux données. Dans LightSwitch, il y a 6 points d'extension illustrés dans le diagramme suivant:
Une manière importante de penser aux extensions est que vous pouvez combiner plusieurs extensions pour créer une expérience basée sur la solution pour le développeur LightSwitch. Un exemple de ceci serait où une extension fournit une solution du marché monétaire en utilisant un Shell qui a une navigation de trading spécifique, un thème spécifique à la société de trading, et un certain nombre de modèles d'écran et de contrôles qui fournissent des visualisations pour les données de trading. Les données peuvent également provenir de diverses sources de données et une source de données personnalisée peut être l'extension qui regroupe les données dans l'application.
LightSwitch utilise Microsoft Extensibility Framework (MEF) qui permet à un développeur de créer une application LightSwitch en utilisant une approche d'architecture centrée sur les modèles. Les extensions sont une combinaison d'assemblys .NET / Silverlight et de métadonnées qui sont empaquetés ensemble et consommés par une application Visual Studio LightSwitch.
Les extensions peuvent fournir une expérience de conception ou d'exécution, ou les deux, en fonction du type d'extension.
Le diagramme suivant montre les étapes de haut niveau de la création d'une extension et de son utilisation par une application LightSwitch.
Le diagramme ci-dessus montre qu'il existe une approche itérative possible dans la conception, la construction et le test de l'extension. Même si une application de test LightSwitch est utilisée, il est tout à fait possible que l'application soit une version plus petite de la solution complète en cours de réalisation.
La structure / mise en page d'extension prend en charge la mise en page de projet physique d'une application Visual Studio LightSwitch. Lorsqu'un développeur crée une application LightSwitch, il ne voit que la structure du projet d'application logique dans l'IDE LightSwitch, comme illustré ci-dessous:
Si vous sélectionnez une vue de fichier et affichez des projets cachés, vous verrez une structure de projet très différente.
La structure du projet ci-dessus montre comment une extension devrait être structurée et développée.
Les extensions sont ajoutées à une application LightSwitch existante via l'environnement de conception
Pendant le développement du temps de conception, une extension de contrôle est ajoutée de la même manière qu'une commande intégrée est ajoutée. Cela garantit que l'expérience dans LightSwitch sera la même quel que soit le type d'extension utilisé.
Le marquage personnalisé peut être affiché à côté du contrôle et également dans les propriétés de contrôle qui nécessitent des informations supplémentaires, dans le cas ci-dessous une clé de licence pour permettre au Bing Map de fonctionner avec le service Web Bing Map.
Dans l'exécution, l'expérience peut être montrée dans l'illustration ci-dessous:
Les extensions se trouvent sur Visual Studio Gallery, où elles peuvent être téléchargées via un navigateur Web ou depuis l'environnement LightSwitch via le gestionnaire d'extensions.
Architecture d'extension LightSwitch
Lors de la conception d'une extension LightSwitch, vous devez prendre en compte deux éléments distincts: la manière dont vous interagissez avec l'extension pendant la conception et la manière dont l'extension est implémentée dans l'environnement d'exécution. En fait, vous pouvez créer une expérience de temps de conception sans aucune implémentation d'exécution en premier. Vous le verrez plus loin dans ce document lorsque vous commencerez à créer des extensions à l'aide de recettes.
La plupart des éléments de conception sont contenus dans un fichier LightSwitch Markup Language ou également appelés lsml. Le fichier lsml ressemble à un fichier xml et est également un fragment de modèle ajouté à votre modèle d'application LightSwitch, de sorte que LightSwitch sait comment il apparaîtra dans l'EDI. Un exemple de ceci est un contrôle dans le concepteur d'écran dans l'arbre visuel, montré ci-dessous:
Ou dans le concepteur d'entité, illustré ci-dessous:
Si vous passez à l'affichage des fichiers, nous pouvons voir le fichier ApplicationDefinition.lsml, qui est le fichier modèle de l'application LightSwitch. Dans ce cas, il s'agit du modèle de l'exemple d'application VisionClinic.
Dans une extension, il existe un fragment de modèle qui fournit des métadonnées à l'application LightSwitch et est intégré à la définition d'application ci-dessus.
Voici un exemple de fichier presentation.lsml pour une extension de contrôle.
<?xml version="1.0" encoding="utf-8" ?>
<ModelFragment
xmlns="http://schemas.microsoft.com/LightSwitch/2010/xaml/model"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Control
Name="BingMapControl"
SupportedContentItemKind="Value"
AttachedLabelSupport="DisplayedByContainer"
DesignerImageResource="BingImages::BingMapControl" >
<Control.Attributes>
<DisplayName Value="$(BingMapControl_DisplayName)" />
</Control.Attributes>
<Control.SupportedDataTypes>
<SupportedDataType DataType=":String"/>
</Control.SupportedDataTypes>
<!-- Property overrides -->
<Control.PropertyOverrides>
</Control.PropertyOverrides>
<!-- BingMapControl Properties -->
<Control.Properties>
<!-- DefaultBingMapControl Property -->
<ControlProperty Name="ApplicationKey"
PropertyType=":String"
IsReadOnly="False"
CategoryName="Bing Map Properties"
EditorVisibility="PropertySheet">
<ControlProperty.Attributes>
<DisplayName Value="$(BingMapControl_ApplicationKey_DisplayName)"/>
<Description Value="$(BingMapControl_ApplicationKey_Description)"/>
</ControlProperty.Attributes>
</ControlProperty>
<!-- End DefaultBingMapControl Property-->
</Control.Properties>
<!-- End BingMapControl Properties-->
</Control>
</ModelFragment>
Afin de rassembler ces concepts, vous devez d'abord comprendre un peu l'architecture LightSwitch. L'architecture LightSwitch est une approche basée sur un modèle et utilise l'architecture du modèle View View.
Le diagramme ci-dessus illustre le concept d'un type d'entreprise (un type d'extension spécifique). Vous pouvez voir la vue, le modèle de vue, le modèle, mais vous devez également noter ici que vous ne pouvez pas accéder au modèle directement depuis la vue (UI). C'est un concept important à comprendre. La façon dont vous pouvez accéder au modèle passe par le modèle de vue utilisant un élément de contenu, qui construit une matrice de la vue et des éléments du modèle.
Où vivent les différents éléments de code que vous créez? Tous les contrôles présentés dans le runtime (un UIElement) résident dans la couche View et résident également dans le projet client de l'application LightSwitch lorsqu'une extension est ajoutée à une application LightSwitch. L'élément de contenu fait partie de LightSwitch et est également le calque View-Model.
La couche suivante est le modèle, qui dans le diagramme ci-dessus est une intersection de projets communs et de serveurs. En regardant la partie commune du diagramme, c'est là que le fichier lsml est créé et défini. Ce qui est unique à propos de cet emplacement et de ce fichier, c'est qu'il fournit des définitions de modèle pour les projets client et serveur, en temps de conception et d'exécution. Considérez-le comme un moyen de partager des informations de code et de modèle communes pour votre extension dans l'application LightSwitch.
Ce qui est intéressant ici, c'est que nous parlons de projets clients, communs, qui constituent une extension LightSwitch, c'est également la même chose pour une application LightSwitch, sauf que les assemblys d'extension vont dans ClientGenerated, Common et ServerGenerated. Pour qu'une extension place les bons assemblages dans les bons emplacements, dans le développement de l'extension LightSwitch, nous avons la notion de désignations. Considérez les désignations comme des pointeurs lorsqu'une extension est décompressée et que des bits de l'extension sont placés au bon endroit pour une application LightSwitch.
Il existe des désignations supplémentaires qui fonctionnent sur les différents projets, ce qui, selon l'extension, ne leur permet d'apparaître qu'à certains endroits de l'expérience de conception et d'exécution. Vous en apprendrez plus sur les désignations plus loin dans ce document.
Let'â € ™ s passons maintenant à la façon dont une extension est empaquetée. Voici un diagramme de haut niveau qui montre quels projets d'extension sont nécessaires pour la fonctionnalité d'extension. Ces projets sont ensuite enveloppés dans un fichier zip appelé un paquet LsPkg. En fait, vous pouvez renommer l'extension du fichier en zip et vous pourrez alors ouvrir le fichier et regarder à l'intérieur.
Le fichier LsPkg contient les assemblys compilés des projets dans la solution d'extension ainsi que certaines métadonnées et des manifestes qui indiquent où les assemblages doivent aller lorsqu'ils sont décompactés (désignations).
Les projets sont des types de projets spécifiques basés sur les fonctionnalités qu'ils doivent fournir dans l'extension. Le tableau suivant présente la répartition des projets, des types et généralement ce qui s'y trouve.
...
Le package LsPkg est ensuite enveloppé dans un fichier de package VSIX. Ceci est un paquet VSIX standard, sauf pour ce qui suit:
La première illustration montre le type de SKU spécifique à fournir. Cela garantit que l'extension n'est utilisée que pour LightSwitch.
La deuxième illustration montre l'inclusion de LsPkg dans le package VSIX en tant que type d'extension personnalisé.
Lorsque vous utilisez les modèles de projets LightSwitch Extensibility, ces détails sont pris en compte pour vous, mais il est important de savoir ce qui se passe dans les coulisses.
Les désignations sont définies dans les propriétés du projet LsPkg.
L'aspect important des désignations dans les propriétés du projet LsPkg est que certains types de projets nécessitent les désignations appropriées. Le tableau suivant montre une matrice des projets nécessaires et des désignations nécessaires pour un type d'extension donné
Pour revenir sur ce qui a été couvert, vous avez appris l'architecture d'une application LightSwitch et comment l'extension est superposée / fusionnée dans une extension composée de plusieurs projets et désignée aux emplacements appropriés lorsqu'elle est ajoutée et décompressée dans une extension. Application LightSwitch. Enfin, vous avez appris sur le format d'emballage pour une extension.
Ajout d'une extension à une application LightSwitch
Donc, la grande question demeure - après avoir construit une extension, comment est-ce que cela se passe dans une application LightSwitch? Cela dépend de la façon dont vous voulez livrer votre extension. Le fichier final d'extension est un fichier Vsix, qui peut être placé sur un serveur de fichiers, envoyé par courrier électronique et téléchargé dans la galerie en ligne de Visual Studio.
Les deux premières méthodes nécessitent un simple clic sur le fichier Vsix. Pour la galerie en ligne, vous pouvez télécharger le fichier Vsix à partir de votre navigateur, ou si vous voulez un sentiment plus intégré, alors cela peut être fait via l'interface Visual Studio Extension Manager.
Un paquet Vsix arrive sur l'ordinateur d'un développeur via un certain nombre de façons. Un moyen est via la galerie Visual Studio comme déjà montré. Le développeur peut aller sur le site Web et télécharger le package manuellement ou l'obtenir directement via Visual Studio LightSwitch en utilisant le gestionnaire d'extensions. Si l'extension est en cours de développement en interne, le paquetage vsix peut être stocké dans un outil de gestion de code source, sur un partage de fichiers, et même envoyé par e-mail à d'autres développeurs.
Une fois que le package extension vsix a été installé sur l'ordinateur du développeur, il est disponible pour une utilisation dans un projet LightSwitch.
Figure 1. Installation d'un package vsix sur un ordinateur à l'aide du programme d'installation autonome vsix.
Pour utiliser l'extension, vous devez avoir un projet LightSwitch existant ouvert, ou vous pouvez en créer un nouveau. À ce stade, vous pouvez sélectionner la page Propriétés de l'application et ouvrir l'onglet Extensions pour voir la liste des extensions disponibles.
Figure 2. Page Extensions dans les propriétés de l'application LightSwitch.
C'est à ce stade que le développeur LightSwitch peut sélectionner une ou plusieurs extensions à utiliser dans le projet en cours, ou choisir de rendre une extension disponible pour tous les futurs projets.
L'extension illustrée ici dans cet exemple est un type d'entreprise appelé PackagingSKU. Pour l'utiliser dans LightSwitch, vous allez d'abord créer une application et activer l'extension. À partir de là, vous allez créer une entité appelée «Products» qui a deux propriétés, ProductName et SKU, illustrées à la figure 3. Depuis que vous avez installé l'extension Business Type, vous pouvez sélectionner le type de SKU Packaging. comme le montre la figure 2.
Figure 3. Concepteur d'entités sur le type d'activité ajouté
L'étape suivante consiste à créer l'écran et à sélectionner les contrôles qui fonctionneront avec l'entité Products comme indiqué dans la figure 4 ci-dessous.
Figure 4. Screen Designer et sélection du contrôle de l'éditeur
Ici, le contrôle SKU est sélectionné et la version de l'éditeur sur le contrôle est utilisée, ce qui permet de saisir des données. Ensuite, vous pouvez exécuter cette application et observer le comportement du type d'entreprise PackagingSKU.
Si le SKU est entré correctement sur l'écran, la validation n'est pas déclenchée. Cependant, si les données sont incorrectement saisies, le format du SKU n'est pas valide, et le message de validation apparaît comme indiqué dans la figure 5 ci-dessous.
Figure 5. L'utilisation d'une extension de type d'entreprise sur un écran déclenchera la validation lors de la saisie des données
Types d'extension LightSwitch
Les types d'extension sont des points d'extensibilité spécifiques dans l'environnement d'application LightSwitch. Il existe six types d'extensions différents. Ce qui suit est une liste des types d'extension et des descriptions de leurs capacités.
Contrôles
Ce type d'extension est un bloc de construction pour le développement d'extensions. La raison en est que l'utilisateur interagit avec un contrôle. Les contrôles apparaissent dans le concepteur d'écran, ils ont une représentation au moment du design dans l'arborescence visuelle, qui peut inclure une icône d'image personnalisée pour fournir une expérience de marque pour le contrôle. Le contrôle peut également avoir des propriétés pour fournir des informations définies par l'utilisateur pour que le contrôle se comporte d'une manière particulière. La façon de laisser le concepteur d'écran interpréter le contrôle et le type de comportement que le contrôle implémentera au moment de la conception est via les métadonnées dans le fichier lsml. Chaque extension nécessite des métadonnées contenues dans un fragment de modèle dans le fichier lsml. Une extension de contrôle en fait un usage intensif. Les contrôles ont besoin des informations de base suivantes dans les métadonnées. Si vous utilisez les modèles de projet d'extensibilité, cela est automatiquement fourni pour vous.
Voici les informations par défaut qui doivent être fournies:
<Control
Name="BingMapControl"
SupportedContentItemKind="Value"
DesignerImageResource="BingImages::BingMapControl" >
<Control.Attributes>
<DisplayName Value="$(BingMapControl_DisplayName)" />
</Control.Attributes>
<Control.SupportedDataTypes>
<SupportedDataType DataType=":String"/>
</Control.SupportedDataTypes>
<control/>
En fonction de la valeur de type sélectionnée ci-dessus, cela aura un effet sur la façon dont vous implémentez votre code pour représenter le contrôle dans l'environnement d'exécution. Par exemple, lorsque vous accédez à des données d'une entité, la liaison de votre contrôle peut différer en fonction du type de valeur. Une valeur peut accéder à une seule valeur scalaire par {Bindings = Details.Value}, alors qu'accéder à une collection nécessite que la collection soit créée à l'aide de IEnumerable et qu'elle soit remplie en récupérant une collection de valeurs d'une entité via IContentItem. En effet, l'accès direct au modèle via un contrôle n'est pas autorisé et doit passer par le viewmodel via IContentItem. Vous en apprendrez plus sur la façon d'utiliser SupportedContentItemKind dans la recette de contrôle expliquée plus loin dans ce livre de recettes.
Le type de données pris en charge permet au développeur de contrôler étroitement le type de données pouvant être utilisé avec ce contrôle. Le tableau suivant montre les différentes options:
<SupportedDataType DataType = ": Chaîne" />
<SupportedDataType DataType = ": Decimal" />
<SupportedDataType DataType = ": Double" />
<SupportedDataType DataType = ": Guid" />
<SupportedDataType DataType = ": Int16" />
<SupportedDataType DataType = ": Int32" />
<SupportedDataType DataType = ": Int64" />
<SupportedDataType DataType = ": DateTime" />
Une fois le modèle représenté, il nécessite maintenant le code d'implémentation nécessaire. C'est la même approche que la création d'un contrôle Silverlight. La seule différence est si vous souhaitez fournir des fonctionnalités de conception supplémentaires qui peuvent affecter le comportement d'exécution du contrôle. Un bon exemple de ceci est les propriétés. Certaines métadonnées doivent être définies à propos de la propriété pour un contrôle donné ainsi que du code d'implémentation tels que les getters et les setters, les propriétés de dépendances et les fonctions de rappel. Encore une fois, cela est expliqué dans la section recette de ce document.
Un autre aspect important à considérer est que si vous avez plusieurs contrôles qui ont des dépendances les uns sur les autres. Comment montreriez-vous cette expérience dans le concepteur d'écran?
Un exemple de ceci est un contrôle de graphique. Comment cela serait-il représenté dans le concepteur d'écran?
Une façon de procéder pourrait être d'avoir un seul contrôle et d'avoir une boîte de dialogue de propriétés distincte à laquelle l'utilisateur peut accéder via la fenêtre des propriétés pour définir les valeurs nécessaires pour un axe donné, le type de graphique et d'autres propriétés. Légende. Bien que cela puisse être bien dans une expérience de développement de contrôle Silverlight régulière, ce n'est pas l'idéal idéal pour LightSwitch. Il est important de considérer la puissance de l'arbre visuel, regardez comment une grille de données ou un contrôle de liste est utilisé; il y a en fait des commandes enfants qui permettent à l'utilisateur de faire d'autres manipulations sans avoir à aller dans le panneau des propriétés. La même chose pourrait être appliquée au contrôle graphique où vous pourriez avoir des contrôles enfants qui permettent la sélection de différents types de graphiques, ainsi que les différentes valeurs appliquées au graphique sélectionné.
Ce qui suit est une illustration pour vous montrer les différences dans l'arbre visuel.
Un seul contrôle avec des propriétés:
Plusieurs contrôles avec une hiérarchie définie:
Vous pouvez voir dans la capture d'écran ci-dessus qu'il existe plusieurs contrôles enfants sous le contrôle Data Series. Ceci est un facteur important à considérer lors du développement de la collection de contrôles pour utiliser l'arborescence visuelle dans le concepteur d'écran afin de fournir une expérience similaire à celle des contrôles intégrés dans le produit, car le développeur a déjà de l'expérience dans l'utilisation du contrôles.
Modèle d'écran
Une extension de modèle d'écran fournit un gabarit pour la disposition des contrôles dans un concepteur d'écran et pour ce qui apparaîtra dans un écran dans l'application pendant l'exécution.
Un modèle d'écran peut être utilisé dans une application, puis supprimé sans affecter les écrans existants qui ont été créés en utilisant le même modèle. Après avoir ajouté l'extension du modèle d'écran, les modèles d'écran apparaîtront dans la boîte de dialogue Ajouter un nouvel écran, ainsi que plusieurs modèles d'écran intégrés.
Ce qui suit est une illustration de quelques modèles d'écran (écran de recherche de catalogue et écran de détail de catalogue) et de ce qu'ils fournissent, dans la disposition des différents contrôles et l'ordre dans la hiérarchie d'arborescence visuelle:
Type d'entreprise
Les types d'entreprise offrent un moyen de visualiser, de formater, de valider et de stocker des informations / données dans une application LightSwitch en fonction des besoins uniques que vous pouvez avoir pour vos données.
Le diagramme ci-dessus est un flux logique du fonctionnement d'un type d'entreprise, en commençant par la gauche du contrôle et en passant par la droite où les données sont stockées dans le type de stockage et où les attributs sont ornés sur le type d'entreprise personnalisé.
Avec une extension de type métier, elle permet de présenter les données dans l'interface utilisateur, en fonction de certaines règles de mise en forme, de valider les données ajoutées à l'application et de garantir la validation des données une fois les données sauvegardées.
Le diagramme de type d'entreprise présente deux étapes de formatage et de validation. Ceci est unique aux types d'entreprise car la première série d'actions est basée sur l'ajout de données sales (non enregistrées), mais toujours formatées et validées, et lorsque l'opération de sauvegarde est terminée, les données sont formatées et validées de manière appropriée. encore. La raison pour laquelle cela est fait sur le client d'abord est que vous pouvez obtenir une rétroaction immédiate à l'utilisateur et conserver les ressources de niveau intermédiaire. Lorsque l'utilisateur enregistre l'écran, les données doivent être formatées et validées sur le serveur; les données traverseront le réseau une seule fois.
Un aspect unique du travail avec un type d'entreprise est que vous pouvez donner un type de stockage à un alias. Un exemple est que le type de stockage PackagingSKU est une chaîne, mais à des fins de lisibilité, l'alias est PackagingSKU. Les types d'entreprise intégrés tels que PhoneNumber et EmailAddress utilisent cette approche, car ils sont tous deux stockés en tant que chaînes dans la base de données.
