Prendre en charge et convertir des types de champs SharePoint pour les applications Windows Phone
Implémenter la logique de conversion de données pour prendre en charge les types de champs SharePoint dans les applications Windows Phone.
Dans les projets basés sur le modèle d'Application de liste SharePoint Windows Phone, les données de nombreux types de champs SharePoint sont traitées et coordonnées par la logique de conversion par défaut soit approprié pour l'affichage et la manipulation de l'interface utilisateur de Silverlight d'un téléphone de Windows, mais les développeurs peuvent également implémenter leurs propre des routines de gestion des données personnalisées.
Importante
Si vous développez une application pour Windows Phone 8, vous devez utiliser Visual Studio Express 2012 au lieu de Visual Studio 2010 Express. À l’exception de l’environnement de développement, toutes les informations contenues dans cet article s’appliquent à la création d’applications pour Windows Phone 8 et Windows Phone 7. > Pour plus d’informations, voir Guide pratique pour configurer un environnement pour le développement d’applications mobiles pour SharePoint.
Types de champs SharePoint dans les applications Windows Phone
Les listes SharePoint sont constitués par des champs de données (organisées en colonnes) et un champ donné est désigné pour contenir des données d'un certain type (en d'autres termes, les données structurées dans une certaine manière). Ces types sont appelés des types de champ. (Ces types peuvent également être appelées types de colonnes, parce que lorsque vous ajoutez une colonne à une liste SharePoint, vous ajoutez une colonne de champs associés à un certain type de données.) Ces champs sont définis par un schéma XML. Le schéma pour un champ appelé « Order Date » avec un type de données DateTime (représenté par un champ de Date et d'heure dans l'interface utilisateur d'un Microsoft SharePoint Server ) peut se présenter comme suit.
<Field Type="DateTime" DisplayName="Order Date" Required="FALSE"
EnforceUniqueValues="FALSE" Indexed="FALSE" Format="DateOnly"
FriendlyDisplayFormat="Disabled" Name="Order_x0020_Date">
<Default>[today]</Default>
<DefaultFormulaValue>2012-01-10T00:00:00Z</DefaultFormulaValue>
</Field>
Notez en particulier la valeur de l'attribut Type de l'élément Field dans ce schéma spécifié ici comme « DateTime ». Les champs de liste créés pour contenir les données structurées par d'autres moyens peuvent être désignés avec une valeur Type, dites, « Choice » ou « Texte » ou « Boolean ».
Types de champs SharePoint ne peut pas être directement liés à des contrôles Silverlight dans une application Windows Phone. Les données qu'il se trouve dans la liste SharePoint doivent être préparées ou traitées d'une certaine façon (ou, dans la terminologie standard de liaison de données Silverlight, converti) afin d'être liés aux contrôles dans l'application et cette préparation et la coordination est géré par les ViewModel dans les projets créés à partir du modèle d'Application de liste SharePoint Windows Phone. Projets basés sur ce modèle sont conçus pour inclure la logique de conversion par défaut pour prendre en charge la liaison et l'affichage des données SharePoint dans une application Windows Phone pour un nombre de types de champs SharePoint standard (ou pour les champs personnalisés créés en fonction d'un de ces types standard). Les types de champs pris en charge avec la logique de conversion par défaut sont répertoriés dans le tableau 1.
Tableau 1. Types de champs avec dispositions pour la conversion par défaut
| Type de champ SharePoint | Type de données de Silverlight |
|---|---|
| Pièces jointes | Fichier |
| Booléen | Booléen |
| Calculé (uniquement pour l'affichage) | Chaîne |
| Choix | Chaîne |
| Devise | Numérique |
| Date/heure | Date (représentée en fonction des paramètres régionaux sur le téléphone) |
| URL | Lien |
| Entier | Numérique |
| Location | GeoCoordinate |
| Recherche | Chaîne |
| Multichoice | Chaîne |
| Remarque | String |
| Nombre | Numérique |
| OutcomeChoice | Chaîne |
| Image | Lien |
| Texte | Chaîne |
| Utilisateur | Chaîne |
Autres types de champs SharePoint, tels que les champs Guid, peuvent être utilisés dans les applications Windows Phone, mais les développeurs ont besoin fournir la logique de conversion personnalisée pour prendre en charge la liaison et affichant les valeurs de ces types de champs pour l'aucune valeur par défaut la logique de conversion a été fournie. (Reportez-vous à la section Logique de conversion personnalisée pour mettre en service les types de champs non pris en charge dans cet article).
Pour illustrer comment le modèle fournit une prise en charge et conversion par défaut pour certains types de champs, supposent que SharePoint liste inclut une colonne de champs nommé « Catégorie de produits « désignée avec un type de Choice et associé à plusieurs options, telles que « La recréation » et « Culinary ». Le schéma de ce type de champ sur le serveur pourrait être représentée par le balisage suivant.
<Field Type="Choice" DisplayName="Product Category" Required="FALSE"
EnforceUniqueValues="FALSE" Indexed="FALSE" Format="Dropdown"
FillInChoice="TRUE"
Name="Product_x0020_Category">
<Default>Recreation</Default>
<CHOICES>
<CHOICE>Culinary</CHOICE>
<CHOICE>Recreation</CHOICE>
<CHOICE>Sartorial</CHOICE>
<CHOICE>Travel</CHOICE>
<CHOICE>Other</CHOICE>
</CHOICES>
</Field>
Ce champ Choice doit être traité afin de pouvoir être affichée dans l'interface de Windows Phone. Dans ce cas, les données dans le champ sont représentées sous forme de chaîne (par exemple, « recréation ») au sein d'une collection de valeurs de chaîne (en particulier, comme une des valeurs de la propriété FieldValuesAsText d'un objet ListItem ). La logique de conversion pour les champs de Choice extrait cette chaîne pour l'afficher dans l'interface utilisateur du téléphone. La chaîne peut être liée au et affichée dans un contrôle TextBlock dans un formulaire. Si la valeur est présentée pour modification, la logique de conversion par défaut pour les champs de Choice extrait les options disponibles pour le champ (« Culinaire », « La recréation », « Parfois », etc.) à partir du schéma XML qui définit le champ et représente les macros complémentaires disponibles options une collection (en particulier, comme un type de la collection en fonction de la classe ObservableCollection(T) ) des objets qu'eux-mêmes incluent l'option spécifique (par exemple « Culinaires ») et si cette option a été sélectionnée. Ces opérations sont gérées dans la couche ViewModel de l'application. Dans la couche de vue (ou présentation) (qui est, dans le fichier XAML générée pour le formulaire de modification par le modèle d'Application de liste SharePoint Windows Phone), ces options sont rendues par défaut comme Silverlight RadioButton contrôles au sein d'un contrôle ListBox.
Conversion personnalisée pour les types de champs SharePoint
Dans les projets Visual Studio basés sur le modèle d'Application de liste SharePoint Windows Phone, le mécanisme de gestion de la coordination et la conversion des données entre SharePoint et l'interface utilisateur Silverlight pour Windows Phone a été conçu pour être flexible et extensible.
Selon la volonté de conception pour votre application, vous souhaiterez peut-être fournir la logique de conversion pour prendre en charge la liaison et l'affichage des types de champs SharePoint qui ne sont pas fournis avec la logique de conversion par défaut, ou vous souhaiterez peut-être afficher les données d'un champ pris en charge d'une manière qui diffère de l'implémentation par défaut.
Projets basés sur le modèle d'Application de liste SharePoint Windows Phone implémentent une classe statique Converter qui inclut des routines d'inscription des méthodes permettant de gérer la conversion opérations spécifiques aux donné des types de données. Le projet comprend et enregistre les routines de conversion de données pour certains types de données par défaut. Le mécanisme d'inscription utilise des délégués pour permettre l'extensibilité. Les développeurs peuvent donc écrire leurs propres fonctions pour fournir la logique pour les conversions de données et ces fonctions personnalisées peuvent être appelées lorsque les délégués sont appelées au lieu des fonctions par défaut. Pour organiser des fonctions personnalisées à appeler pour les opérations de conversion de données, enregistrer les fonctions de la classe Converter utilisant les méthodes d'inscription de la classe. L'inscription de méthodes sont spécifiques à chaque ViewModel, pour prendre en charge la possibilité que vous souhaiterez peut-être mettre en œuvre et enregistrer des différentes fonctions pour traiter les données différemment en fonction de, par exemple, si les données seront présentées pour édition ou affichage uniquement (sans modification).
Conseil
[!CONSEIL] Le symbole monétaire indiqué dans le formulaire d'affichage est à partir de paramètres régionaux de SharePoint, même si les paramètres régionaux Windows Phone sont différente. Les développeurs peuvent personnaliser ce comportement en utilisant les objets Converter.
Pour enregistrer les fonctions de conversion de données pour le formulaire d'affichage (DisplayForm.xaml), utilisez la méthode RegisterDisplayFieldValueConverter de la classe Converter. Pour enregistrer les fonctions pour le formulaire de modification (EditForm.xaml), utilisez la méthode RegisterEditFieldValueConverter et pour le nouveau formulaire (NewForm.xaml), utilisez la méthode RegisterNewFieldValueConverter.
Vous pouvez inscrire des fonctions de conversion qui traitent les données qu'il s'agit de la liste à présenter dans l'interface utilisateur (autrement dit, les fonctions qui déterminent comment obtenir les données) et vous pouvez inscrire des fonctions qui traitent les données à partir de l'interface utilisateur en tant que son enregistré à la liste sur le serveur (fonctions qui déterminent comment l'ensemble de données).
Les fonctions get doivent correspondre à la signature de la déclaration de délégué suivant dans la classe Converter.
public delegate object GetConvertedFieldValue(string fieldName,
ListItem item, ConversionContext context);
Les fonctions de la valeur doivent correspondre à la signature de la déclaration de délégué suivantes.
public delegate void SetConvertedFieldValue(string fieldName,
object fieldValue, ListItem item, ConversionContext context);
La méthode RegisterDisplayFieldValueConverter accepte une fonction obtenir uniquement, étant donné que la classe DisplayItemViewModel, comme prévu, est destinée à afficher, mais pas modifier les données. Les RegisterEditFieldValueConverter et les méthodes RegisterNewFieldValueConverter sont surchargées afin qu'il accepte une fonction get, une fonction définie ou les deux.
Dans Guide pratique pour implémenter la logique métier et la validation des données dans une application Windows Phone pour SharePoint, une routine de validation a été développée pour vérifier le format ou les numéros de téléphone fournis par l’utilisateur d’une application Windows Phone. To demonstrate custom data conversion, in the following code sample, we'll implement get and set functions to handle phone number data in a particular way and register those functions to be used in the Edit and New forms with the Converter class.
Supposons que pour les besoins de l'exemple de code suivant que vous avez créé une application Windows Phone SharePoint de liste basée sur une liste de commandes de produits créée à l'aide du modèle de liste personnalisée sur le serveur. Supposons que la liste contient un champ appelé « Numéro de Contact » et que ce champ est désigné comme un champ Text dans la liste. Dans la configuration par défaut d'un champ de liste désigné comme un type de Text sur un SharePoint Server, un utilisateur peut entrer les caractères de texte (255 caractères au maximum). Le modèle fournit la logique de conversion par défaut pour l'affichage et modification des données à partir des champs de Text dans SharePoint, mais un champ Text (par défaut) n'est pas structurée pour imposer ou afficher toute mise en forme spécifique, telle que peut être appliquée par convention aux numéros de téléphone. Dans votre application Windows Phone, vous pouvez vouloir des numéros de téléphone à afficher aux utilisateurs d'une manière cohérente et, lors de l'enregistrement à la liste sur le serveur, la mise en forme d'une façon particulière, même si le type de champ sous-jacent ( Text) n'est pas associé à des règles de mise en forme spécifiques. Pour appliquer vos règles de mise en forme particulière, vous pouvez implémenter votre propre logique de conversion de données personnalisées à la place de la logique par défaut pour un type de champ pris en charge.
Pour implémenter la conversion de données personnalisées
En supposant que vous avez créé une liste sur un serveur SharePoint qui inclut un champ Texte nommé « Numéro de contact » (comme la liste d’exemples commandes de produits utilisée dans Guide pratique pour implémenter la logique métier et la validation des données dans une application Windows Phone pour SharePoint), créez une application Windows Phone à l’aide du Windows Phone Modèle d’application de liste SharePoint dans Visual Studio en suivant les étapes décrites dans How to: Create a Windows Phone SharePoint list app.
Dans L'Explorateur de solutions, choisissez le nœud qui représente le projet (nommé, par exemple, ContosoSPListApp).
Dans le menu projetVisual Studio (ou Visual Studio Express pour Windows Phone), cliquez sur Ajouter une classe. La boîte de dialogue Ajouter un nouvel élément s'ouvre avec le modèle de classe c# déjà sélectionné.
Spécifiez un nom pour le fichier de classe (par exemple, ContosoConverter.cs) et cliquez sur Ajouter. Le fichier de classe est ajouté au projet et ouvert pour modification.
Remplacez le contenu du fichier par le code suivant.
using System; using Microsoft.SharePoint.Client; // Added for ListItem. using Microsoft.SharePoint.Phone.Application; // Added for ConversionContext. using System.Text.RegularExpressions; // Specify a namespace appropriate for your particular project. namespace ContosoSPListApp { public static class ContosoConverter { static Regex StandardNumberFormat = new Regex(@"^\\(?([0-9]{3})\\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$", RegexOptions.Compiled); public static object GetConvertedTextFieldValue(string fieldName, ListItem item, ConversionContext context) { if (item == null) return null; if (fieldName == "Contact_x0020_Number") { string contactNumber = string.Empty; try { contactNumber = item.FieldValuesAsText[fieldName]; } catch (PropertyOrFieldNotInitializedException) { object itemValue = item[fieldName]; if (itemValue != null) { contactNumber = itemValue.ToString(); } } // Regularize the formatting of phone number for display in UI. if (StandardNumberFormat.IsMatch(contactNumber)) { // Phone number is in an acceptable format, but formatting it // in a specific way for visual consistency in the UI. string properlyFormattedNumber = StandardNumberFormat.Replace(contactNumber, "($1) $2-$3"); return properlyFormattedNumber; } else { // Return a representation of the data adorned in such a way // as to designate its invalidity. if (!contactNumber.Contains("Invalid Number")) { return string.Format("Invalid Number: {0}", contactNumber); } else { // Assume data is already adorned with an invalidity designation. return contactNumber; } } } else { return item[fieldName]; } } public static void SetConvertedTextFieldValue(string fieldName, object fieldValue, ListItem item, ConversionContext context) { if (fieldValue == null) return; if (fieldName == "Contact_x0020_Number") { // Conventional formats (e.g., 555-555-5555) are acceptable, // but formatting phone numbers consistently here for storage in list on Server. string contactNumber = (string)fieldValue; if (StandardNumberFormat.IsMatch(contactNumber)) { string properlyFormattedNumber = StandardNumberFormat.Replace (contactNumber, "($1) $2-$3"); item[fieldName] = properlyFormattedNumber; } else { if (!contactNumber.Contains("Invalid Number")) { item[fieldName] = string.Format("Invalid Number: {0}", contactNumber); } else { // Assume data is already adorned with an invalidity designation. item[fieldName] = contactNumber; } } } else { // Allow values for other Text fields to be passed on to list without modification. item[fieldName] = fieldValue; } } } }Enregistrez le fichier.
La fonction GetConvertedTextFieldValue ici détermine si chaîne de données à partir d'un champ destiné à contenir un numéro de téléphone (appelé « Nombre de contacts » dans cet exemple) est mis en forme conformément aux conventions standard pour les numéros de téléphone (Amérique du Nord) et, si tel est le cas, convertit un nombre en un format spécifique pour l'affichage, « (XXX) XXX-XXXX ». Si les données ne sont pas mis en forme comme un numéro de téléphone standard, il est précédé d'un indicateur. Cette fonction ne change pas réellement les données dans la liste. La fonction SetConvertedTextFieldValue, se déroule en revanche, dans le sens inverse. Il vérifie la valeur des données fournies pour un champ par un utilisateur pour déterminer si les données fournies correspondant au modèle pour les numéros de téléphone standard ou non. Si tel est le cas, la valeur fournie est convertie en un format spécifique d'être enregistrées dans la liste sur le serveur. Si la valeur fournie n'est pas dans un format standard, la valeur est préfixée avec un indicateur et que la valeur préfixé est ensuite enregistrement sur le serveur.
Il reste maintenant pour enregistrer ces fonctions de conversion de données avec la classe de convertisseur à utiliser sur les formulaires de modification et nouveau. Vous pouvez inscrire les convertisseurs à plusieurs endroits. Dans la procédure suivante, les convertisseurs sont enregistrées dans l'événement OnNavigatedTo du formulaire de liste (List.xaml). Le formulaire de liste est créé et dirigé vers avant que les formulaires de modification et nouveau sont instanciés dans l'application, afin que les convertisseurs inscrits dans cet événement dans le formulaire de liste prendra effet pour les champs de texte dans tous les formulaires.
Pour enregistrer les fonctions de conversion de données
Dans L'Explorateur de solutions pour le même projet dans lequel vous avez créé la classe dans la procédure précédente, choisissez le fichier List.xaml sous le nœud de vues.
AppuyezF7Pour ouvrir le fichier code-behind associé, List.xaml.cs, pour la modification.
Ajoutez la déclaration de variable privée suivante au début du bloc de code qui implémente la classe partielle ListForm, après l'accolade ouvrante dans le bloc de code et avant que le constructeur
ListForm().private bool _isConversionRegistered;Ajoutez la méthode suivante, RegisterTextFieldValueConverters, dans le fichier, dans le bloc de code (délimité par ouvrante et fermante accolades) qui implémente la classe partielle ListForm.
private void RegisterTextFieldValueConverters() { Converter.RegisterEditFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); Converter.RegisterNewFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); }Cette méthode appelle simplement les méthodes d'enregistrement appropriées de la classe Converter. Pour que ce code, il est supposé que la classe personnalisée contenant les fonctions get et set créées dans la procédure précédente est nommée « ContosoConverter ». Si vous avez spécifié un autre nom pour votre classe, modifiez le code ici en conséquence.
Modifiez l'implémentation du Gestionnaire d'événements OnNavigatedTo dans le fichier en ajoutant une vérification de la valeur de l'indicateur _isConversionRegistered et un appel à la fonction RegisterTextFieldValueConverters ajouté à l'étape précédente. Le Gestionnaire de modification doit être comme suit.
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e) { base.OnNavigatedTo(e); App.MainViewModel.ViewDataLoaded += new EventHandler<ViewDataLoadedEventArgs>(OnViewDataLoaded); App.MainViewModel.InitializationCompleted += new EventHandler<InitializationCompletedEventArgs>(OnViewModelInitialization); // The OnNavigatedTo event can fire more than once, but the converters only need // to be registered once, so checking the conversion flag first. if (_isConversionRegistered == false) { // Register converters. RegisterTextFieldValueConverters(); _isConversionRegistered = true; } }Enregistrez le fichier.
Notez que les fonctions de conversion de données sont enregistrées pour tous les champs associés à un type de données Text dans les formulaires de modification et nouveau. C'est pour cette raison que les fonctions de obtenir et définir implémentées pour la classe ContosoConverter créée dans la procédure précédente incluent les vérifications conditionnelles pour traiter les données pour un champ particulier uniquement (nommé, dans ce cas, « Contact_x0020_Number »), ce qui permet les données « franchir » pour les autres champs Text.
Logique de conversion personnalisée pour mettre en service les types de champs non pris en charge
Même si vous ne fournissez pas logique de conversion dans votre application pour les champs de Text, ces champs peuvent toujours sont affichées et modifiées. Fourniture de votre propre logique de conversion pour les champs qui sont déjà fournis avec la logique de conversion par défaut vous offre une plus grande contrôle sur le format ou la structure des données dans ces champs si la logique par défaut n'est pas adaptée à vos intentions de conception. Pour les champs dont certains autres types de données, comme des champs de Guid, la logique de conversion n'est pas fournie par défaut, mais si vous comprenez le mécanisme (décrit dans la section précédente) à laquelle la logique de conversion est fournie pour les champs, il peut être assez simple de fournir votre propre logique de conversion pour prendre en charge les types de champs dans votre application et qui ne sont pas pris en charge avec la logique par défaut par le modèle d'Application de liste SharePoint Windows Phone.
Supposons que vous créez une application Windows Phone basée sur une liste SharePoint nommée identificateurs de produit, qui inclut un champ avec un type de données Guid. Pour les besoins de l'exemple de code suivant, supposons que la liste a un champ produit (ou titre) (de type Text) et un champ d'identificateur (de type Guid).
Remarque
[!REMARQUE] Listes SharePoint avec des champs de Guid doivent être créés par programme ou à partir d'un modèle de liste qui inclut les champs de Guid.
Dans une application Windows Phone créée à l'aide du modèle et en fonction de cette liste simple, les données dans les champs Guid ne sont pas affichées par défaut. (À la place de ces données, un message semblable à ce qui suit s'affiche: « Aucun convertisseur pour le type de champ 'Guid' n'est inscrit ».) Dans la procédure suivante, vous allez inclure une logique de conversion pour prendre en charge des champs de Guid pour une application Windows Phone. Pour ajouter une classe qui contient des méthodes pour inscrire les convertisseurs de valeur de champ pour afficher les identificateurs GUID et de générer des nouvelles valeurs GUID pour les éléments de l'ajout d'une liste.
Pour fournir la logique de conversion d'un type de champ non pris en charge
Dans un projet (nommé, par exemple, SPListAppGuidConversion) créé à partir de l'Application de liste SharePoint Windows Phone et en fonction de la liste d'identificateurs de produit mentionnée ci-dessus, choisissez le nœud qui représente le projet dans L'Explorateur de solutions.
Dans le menu Projet, choisissez Ajouter une classe. La boîte de dialogue Ajouter un nouvel élément s'affiche avec le modèle Classe C# déjà sélectionné.
Spécifiez GuidConversion.cs comme nom du fichier, puis choisissez Ajouter. Le fichier de classe est ajouté à la solution et ouvert pour modification
Remplacez le contenu du fichier par le code suivant.
using System; using Microsoft.SharePoint.Phone.Application; using Microsoft.SharePoint.Client; namespace SPListAppGuidConversion { public class GuidConversion { /// <summary> /// Registers a GET converter to prepare GUID values for display. /// </summary> static public void RegisterDisplayFieldGuidConverter() { // Register GET converter to display GUID values. Converter.RegisterDisplayFieldValueConverter(FieldType.Guid, getConvertedFieldValue: (string fieldName, ListItem item, ConversionContext context) => { string guidValue = string.Empty; try { guidValue = item.FieldValuesAsText[fieldName]; } catch (PropertyOrFieldNotInitializedException) { object itemValue = item[fieldName]; if (itemValue != null) { guidValue = itemValue.ToString(); } } if (string.IsNullOrWhiteSpace(guidValue)) { return string.Format("{{{0}}}", Guid.Empty); } else { Guid g = new Guid(); if (Guid.TryParse(guidValue, out g)) { guidValue = string.Format("{{{0}}}", g.ToString().ToUpper()); return guidValue; } else { return "Invalid Identifier (GUID)"; } } }); } /// <summary> /// Registers GET and SET converters for GUID value of new (i.e., added) list items. /// </summary> public static void RegisterNewFieldGuidConverter() { Converter.RegisterNewFieldValueConverter(FieldType.Guid, getConvertedFieldValue: (string fieldName, ListItem item, ConversionContext context) => Guid.NewGuid().ToString(), setConvertedFieldValue: (string fieldName, object fieldValue, ListItem item, ConversionContext context) => { if (fieldValue == null) { item[fieldName] = Guid.Empty.ToString(); } else { item[fieldName] = fieldValue; } }); } } }Dans cette classe personnalisée, la RegisterDisplayFieldValueConverter et des méthodes de la classe ConverterRegisterNewFieldValueConverter sont appelés à l'aide des fonctions anonymes (définies par une expression lambda instruction) à mettre en œuvre les routines get et set pour les délégués requis par les méthodes d'inscription. L'argument facultatif étiquettes ici (par exemple, « getConvertedFieldValue: ») sont inclus dans ce code uniquement pour clarifier les délégués sont définis.)
Cette approche, qui implique des expressions lambda, est une alternative au passage de fonctions nommées en tant que paramètres aux fonctions d’inscription du convertisseur, comme illustré dans une procédure précédente décrite dans cette rubrique (dans la section Pour inscrire les fonctions de conversion de données).
Enregistrez le fichier.
Dans L'Explorateur de solutions, choisissez le fichier App.xaml.
AppuyezF7Pour ouvrir le fichier code-behind associé, App.xaml.cs, pour la modification.
Localisez l'implémentation du Gestionnaire d'événements Application_Launching (qui est vide dans un nouveau projet créé à partir du modèle d'Application de liste SharePoint Windows Phone) et remplacez-la par le code suivant.
private void Application_Launching(object sender, LaunchingEventArgs e) { // Register converters for GUID fields. Converters can be // registered just once for the app. GuidConversion.RegisterDisplayFieldGuidConverter(); GuidConversion.RegisterNewFieldGuidConverter(); }Pour la logique du convertisseur à utiliser pour les nouveaux éléments de liste (autrement dit, générer les GUID des valeurs lorsque les éléments sont ajoutés à la liste), vous devez vous assurer que le champ d'identificateur de l' NewItemViewModel est lié au nouveau formulaire. Une façon d'effectuer cette opération est en ajoutant un contrôle masqué TextBlock NewForm.xaml avec une déclaration Binding pour sa propriété Text définie dans le champ identificateur. Vous pouvez ajouter le contrôle TextBlock pour le contrôle conteneur StackPanel qui inclut le contrôle TextBox pour le champ titre, comme indiqué dans la section suivante du balisage dans le fichier NewForm.xaml.
<Grid x:Name="LayoutRoot" Background="Transparent" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:controls="clr-namespace:Microsoft.Phone.Controls; assembly=Microsoft.Phone.Controls"> <StackPanel> <ProgressBar Background="Red" x:Name="progressBar" Opacity="1" HorizontalAlignment="Center" VerticalAlignment="Top" Height="15" Width="470" IsIndeterminate="{Binding IsBusy}" Visibility="{Binding ShowIfBusy}" /> <ScrollViewer HorizontalScrollBarVisibility="Auto" Height="700"> <Grid x:Name="ContentPanel" Width="470"> <StackPanel Margin="0,5,0,5"> <StackPanel Orientation="Vertical" Margin="0,5,0,5"> <TextBlock TextWrapping="Wrap" HorizontalAlignment="Left" Style="{StaticResource PhoneTextNormalStyle}"> Title*</TextBlock> <TextBox Style="{StaticResource TextValidationTemplate}" FontSize="{StaticResource PhoneFontSizeNormal}" Width="470" HorizontalAlignment="Left" Name="txtTitle" Text="{Binding [Title], Mode=TwoWay, ValidatesOnNotifyDataErrors=True, NotifyOnValidationError=True}" TextWrapping="Wrap" /> <TextBlock Name="txtIdentifier" Text="{Binding [Identifier]}" Visibility="Collapsed"/> </StackPanel> </StackPanel> </Grid> </ScrollViewer> </StackPanel> </Grid>Enregistrez le fichier.
Si vous démarrez le projet et déployez l'application sur l'émulateur de Windows Phone pour l'exécuter, les données dans le champ identificateur s'affiche dans le formulaire de liste (List.xaml) si le champ correspondant dans la liste SharePoint contient une valeur GUID. (Voir la Figure 1).
Figure 1. Affichage des champs de GUID
Dans les projets basés sur le modèle d'Application de liste SharePoint Windows Phone, les contrôles Silverlight ne peuvent pas être ajoutés aux formulaires et liées à des types de champ qui ne sont pas pris en charge avec la logique de conversion par défaut dans le modèle. Pour le champ identificateurs de la liste d'identificateurs de produit utilisé dans la procédure précédente, vous pouvez ajouter des balises au fichier DisplayForm.xaml pour définir des contrôles supplémentaires pour afficher les valeurs GUID, par exemple un contrôle TextBlock et un contrôle TextBox dans un contrôle StackPanel, qui est elle-même contenue dans le contrôle Grid de l'interface utilisateur. Le balisage du contrôle ajouté StackPanel pourrait ressembler à ceci.
<StackPanel HorizontalAlignment="Left" Orientation="Horizontal"
Margin="0,5,0,5">
<TextBlock TextWrapping="Wrap" Width="150" HorizontalAlignment="Left"
Style="{StaticResource PhoneTextNormalStyle}">Identifier:</TextBlock>
<TextBlock Width="310" HorizontalAlignment="Left" Name="txtIdentifier"
Text="{Binding [Identifier]}" TextWrapping="Wrap" Style="
{StaticResource PhoneTextSubtleStyle}" />
</StackPanel>
Le champ identificateur est à présent affiché sur le formulaire d'affichage, ainsi que sur le formulaire de liste.
Voir aussi
- Créer des applications Windows Phone accédant à SharePoint
- Comment : configurer un environnement pour le développement d'applications mobiles pour SharePoint
- Windows Phone SDK 8.0
- Kit de développement logiciel Microsoft SharePoint pour Windows Phone 8
- Windows Phone SDK 7.1
- Microsoft SharePoint SDK pour Windows Phone 7.1