Admitir y convertir los tipos de campo de SharePoint para aplicaciones de Windows Phone
Implemente lógica de conversión de datos para admitir tipos de campo de SharePoint en aplicaciones de Windows Phone.
En proyectos basados en la plantilla Aplicación de lista de SharePoint para Windows Phone, los datos de muchos tipos de campo de SharePoint se procesan y coordinan con la lógica de conversión predeterminada para que sean aptos para su visualización y manipulación en la interfaz de usuario de Silverlight de un Windows Phone, pero los desarrolladores también pueden implementar sus propias rutinas de manipulación de datos personalizadas.
Importante
Si va a desarrollar una aplicación para Windows Phone 8, debe usar Visual Studio Express 2012 en lugar de Visual Studio 2010 Express. Salvo para el entorno de desarrollo, toda la información de este artículo se aplica a la creación de aplicaciones para Windows Phone 8 y Windows Phone 7. > Para obtener más información, vea Cómo: Configurar un entorno para desarrollar aplicaciones móviles para SharePoint.
Tipos de campo de SharePoint en aplicaciones de Windows Phone
Las listas de SharePoint están constituidas por campos de datos (organizados en columnas), se designa un campo dado para que contenga los datos de un tipo determinado (o sea, datos estructurados de una forma determinada). Estos tipos se llaman tipos de campo. (Estos tipos también se pueden denominar tipos de columna, ya que cuando se agrega una columna a una lista de SharePoint, se agrega una columna de campos asociados a un tipo determinado de datos). Estos campos se definen mediante un esquema XML. El esquema de un campo denominado "Fecha de pedido" con un tipo de datos DateTime (representado como campo Fecha y hora en la interfaz de usuario de microsoft SharePoint Server) podría tener un aspecto similar al siguiente.
<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>
Observe en particular el valor del atributo Type del elemento Field en este esquema, especificado como "DateTime". Los campos de lista creados para contener datos estructurados de otras maneras podrían designarse con un valor Type de, por ejemplo "Choice", "Text" o "Boolean".
Los tipos de campo de SharePoint no pueden estar enlazados directamente a controles de Silverlight en una aplicación de Windows Phone. Los datos tal como están en la lista de SharePoint deben preparase o procesarse de cierta manera (o, en la terminología estándar de enlace de datos de Silverlight, convertirse) para enlazarse a los controles en la aplicación, y está preparación y coordinación es manipulada por los ViewModels en proyectos que se crean a partir de la plantilla Aplicación de lista de SharePoint para Windows Phone. Los proyectos basados en esta plantilla están diseñados para incluir lógica de conversión predeterminada con el fin de admitir el enlace y la visualización de datos de SharePoint en una aplicación de Windows Phone para una variedad de tipos de campo de SharePoint estándar (o para campos personalizados creados según uno de estos tipos estándar). Los tipos de campo admitidos con lógica de conversión predeterminada se muestran en la Tabla 1.
Tabla 1. Tipos de campo con provisiones para conversión predeterminada
| Tipo de campo de SharePoint | Tipo de datos de Silverlight |
|---|---|
| Datos adjuntos | Archivo |
| Booleano | Booleano |
| Calculated (para visualización únicamente) | String |
| Choice | String |
| Currency | Numeric |
| DateTime | Date (representado de acuerdo con la configuración regional del teléfono) |
| Dirección URL | Link |
| Entero | Numeric |
| Location | GeoCoordinate |
| Lookup | String |
| MultiChoice | String |
| Note | String |
| Número | Numeric |
| OutcomeChoice | String |
| Picture | Link |
| Texto | String |
| Usuario | String |
En aplicaciones de Windows Phone, es posible usar otros tipos de campo de SharePoint, como los campos Guid, pero los desarrolladores necesitan proporcionar lógica de conversión personalizada para admitir el enlace y la visualización de valores para aquellos tipos de campo para los que no se haya proporcionado lógica de conversión predeterminada. (Vea Lógica de conversión personalizada para aprovisionar tipos de campo no admitidos en este artículo).
A fin de ilustrar de qué manera la plantilla proporciona conversión predeterminada y compatibilidad con tipos de campo específicos, imagine una lista de SharePoint que incluya una columna de campos con el nombre "Product Category" y designada con un tipo de Choice y asociada con varias opciones, como "Recreation" y "Culinary". El esquema para dicho campo en el servidor podría parecerse al siguiente marcado.
<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>
Si se desea que este campo Choice sea apto para su visualización en la interfaz de Windows Phone, se lo debe procesar. En este caso, los datos del campo se representan como una cadena (por ejemplo, "Recreation") dentro de una recopilación de valores de cadena (específicamente, como uno de los valores de la propiedad FieldValuesAsText de un objeto ListItem. La lógica de conversión para campos Choice extrae esta cadena para visualizarla en la interfaz de usuario del teléfono. Esta cadena podría estar enlazada a un control TextBlock en un formulario y visualizarse en el control. Si el valor se presentó para modificación, la lógica de conversión predeterminada para campos Choice extrae las opciones disponibles para el campo ("Culinary", "Recreation", "Sartorial", etc.) del esquema XML que define al campo y representa a esas opciones disponibles como una colección (específicamente, como un tipo de colección basada en la clase ObservableCollection(T)) de objetos que incluyen ellos mismos la opción específica (por ejemplo, "Culinary") y si esa opción fue seleccionada o no. Todas estas tareas se manipulan en la capa ViewModel de la aplicación. En la capa Vista (o Presentación), o sea, en el archivo XAML que la plantilla Aplicación de lista de SharePoint para Windows Phone generó para el formulario Editar, estas opciones están representadas de forma predeterminada como controles RadioButton de Silverlight dentro de un control ListBox.
Conversión personalizada para tipos de campo de SharePoint
En proyectos Visual Studio que se basan en la plantilla Aplicación de lista de SharePoint para Windows Phone, el mecanismo para manipular la coordinación y conversión de datos entre SharePoint y la interfaz de usuario de Silverlight de Windows Phone se diseñó para que sea flexible y se pueda extender.
Según las intenciones para el diseño de su aplicación en particular, es posible que desee proporcionar lógica de conversión para admitir enlace y visualización de tipos de campo de SharePoint que no se proporcionan con lógica de conversión de forma predeterminada. O bien, también es posible que desee visualizar datos para un campo admitido de una manera diferente a la implementación predeterminada.
Los proyectos basados en la plantilla Aplicación de lista de SharePoint para Windows Phone implementan una clase Converter estática que incluye rutinas para registrar métodos para manipular tareas de conversión de datos específicas de tipos de datos determinados. El proyecto incluye y registra rutinas de conversión de datos para ciertos tipos de datos de forma predeterminada. El mecanismo de registro usa delegados para permitir la extensibilidad. Los desarrolladores pueden, por lo tanto, escribir sus propias funciones para proporcionar la lógica para conversiones de datos, y es posible llamar a estas funciones personalizadas cuando se invocan los delegados en lugar de las funciones predeterminadas. Para prever funciones personalizadas con el fin de ser llamadas para tareas de conversión de datos, registre sus funciones con la clase Converter con los métodos de registro de la clase. Los métodos de registro son específicos de cada ViewModel, para prever la posibilidad de que pudiera desear implementar y registrar diferentes funciones para procesar datos de forma diferente según, por ejemplo, si los datos se presentarán para modificación o visualización únicamente (sin edición).
Sugerencia
[!SUGERENCIA] El símbolo de moneda que aparece en el formulario de muestra procede de la configuración regional de SharePoint, aunque la configuración regional de Windows Phone sea diferente. Los desarrolladores pueden personalizar este comportamiento utilizando objetos Converter.
Para registrar funciones de conversión de datos para el formulario Visualización (DisplayForm.xaml), use el método RegisterDisplayFieldValueConverter de la clase Converter. Para registrar funciones para el formulario Edición (EditForm.xaml), use el método RegisterEditFieldValueConverter, y para el formulario Nuevo (NewForm.xaml), use el método RegisterNewFieldValueConverter.
Puede registrar funciones de conversión que procesan datos como se obtienen de la lista para ser presentados en la interfaz de usuario (o sea, funciones que determinan cómo obtener [ get ] datos) y puede registrar funciones que procesan datos a partir de la interfaz de usuario como se guardan en la lista del servidor (funciones que determinan cómo establecer [ set ] datos).
Las funciones get deben coincidir con la firma de la siguiente declaración de delegado en la clase Converter.
public delegate object GetConvertedFieldValue(string fieldName,
ListItem item, ConversionContext context);
Las funciones set deben coincidir con la firma de la siguiente declaración de delegado.
public delegate void SetConvertedFieldValue(string fieldName,
object fieldValue, ListItem item, ConversionContext context);
El método RegisterDisplayFieldValueConverter acepta una función get únicamente, porque la clase DisplayItemViewModel, tal como está designada, tiene el objetivo de mostrar los datos pero no editarlos. Los métodos RegisterEditFieldValueConverter y RegisterNewFieldValueConverter están sobrecargados para aceptar una función get, una función set, o ambas.
En How to: Implement business logic and data validation in a Windows Phone app for SharePoint (Cómo: Implementar lógica empresarial y validación de datos en una aplicación de Windows Phone para SharePoint), se desarrolló una rutina de validación para comprobar el formato o los números de teléfono proporcionados por el usuario de una aplicación Windows Phone. Para demostrar conversión de datos personalizada, en la siguiente muestra de código, implementaremos las funciones get y set para manipular datos de números telefónicos de una manera específica y registrar esas funciones para que se usen en los formularios Edición y Nuevo con la clase Converter.
Supongamos para los fines del siguiente ejemplo de código que usted ha creado una aplicación de lista de SharePoint para Windows Phone basada en una lista Pedidos de productos creada con la plantilla Lista personalizada en el servidor. Suponga que la lista tiene un campo con el nombre "Número de contacto" y que este campo está designado como campo Text en la lista. En la configuración predeterminada de un campo de lista designado como tipo Text en un SharePoint Server, un usuario puede especificar cualquier secuencia de caracteres de texto (hasta 255 caracteres). La plantilla proporciona lógica de conversión predeterminada para visualizar y editar datos de campos Text en SharePoint, pero un campo Text (de forma predeterminada) no está estructurado para imponer o visualizar cualquier formato específico, tal como podría aplicarse convencionalmente a números telefónicos. En su aplicación de Windows Phone, puede necesitar que los números telefónicos se muestren a los usuarios de manera uniforme y, cuando se guardan en la lista del servidor, se les aplica formato de una manera en particular, aunque el tipo de campo subyacente ( Text) no está asociado con reglas de formato específicas. Para aplicar sus reglas de formato en particular, puede implementar su propia lógica de conversión de datos personalizada en lugar de la lógica predeterminada para un tipo de campo admitido.
Para implementar conversión de datos personalizada
Suponiendo que ha creado una lista en una instancia de SharePoint Server que incluye un campo de texto denominado "Número de contacto" (como la lista de ejemplo Pedidos de producto usada en Cómo: Implementar la lógica de negocios y la validación de datos en una aplicación de Windows Phone para SharePoint), cree una aplicación de Windows Phone mediante el Windows Phone Plantilla de aplicación de lista de SharePoint en Visual Studio siguiendo los pasos detallados en Cómo: Crear una aplicación de lista de SharePoint Windows Phone.
En el Explorador de soluciones, elija el nodo que representa al proyecto (denominado, por ejemplo, ContosoSPListApp).
En el menú Proyecto en Visual Studio (o Visual Studio Express para Windows Phone), elija Agregar clase. Se abre el cuadro de diálogo Agregar nuevo elemento con la plantilla Clase de C# ya elegida.
Especifique un nombre para el archivo de clase (como ContosoConverter.cs) y elija Agregar. De esta manera, el archivo de clase se agrega al proyecto y queda abierto para modificación.
Cambie el contenido del archivo por el siguiente código.
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; } } } }Guarde el archivo.
La función GetConvertedTextFieldValue determina si los datos de cadena de un campo pensado para contener un número telefónico (llamado "Número de contacto" en este ejemplo) tiene formato de acuerdo con convenciones estándar para números telefónicos (en América del Norte) y, si es así, convierte el número a un formato específico para visualización, "(XXX) XXX-XXXX". Si los datos no tienen el formato de un número telefónico estándar, se les agrega un prefijo con un designador. La función en realidad no cambia los datos de la lista. La función SetConvertedTextFieldValue, por otra parte, actúa en dirección opuesta. Comprueba el valor de los datos que un usuario proporcionó para un campo con el fin de determinar si los datos proporcionados coinciden con el patrón de números telefónicos estándar o no. En caso afirmativo, el valor proporcionado se convierte a un formato específico para guardarse en la lista del servidor. Si el valor proporcionado no está en un formato estándar, al valor se le agrega un prefijo con un designador y después se guarda ese valor con prefijo en el servidor.
Ahora se deben registrar estas funciones de conversión de datos con la clase Converter para uso en los formularios Edición y Nuevo. Puede registrar los convertidores en varios lugares. En el siguiente procedimiento, los convertidores se registran en el evento OnNavigatedTo del formulario Lista (List.xaml). Esta lista se crea, y se navega a ella, antes de que los formularios Edición y Nuevo se instancien en la aplicación; por lo tanto, los convertidores registrados en este evento en el formulario Lista surtirán efecto para los campos de texto en todos los formularios.
Para registrar las funciones de conversión de datos
En el Explorador de soluciones para el mismo proyecto en que creó la clase del procedimiento anterior, elija el archivo List.xaml dentro del nodo Vistas.
PresioneF7para abrir el archivo de código subyacente asociado, List.xaml.cs, para su edición.
Agregue la siguiente declaración de variable privada a la parte superior del bloque de código que implementa la clase parcial ListForm, después de la llave de abertura en el bloque de código y antes del constructor
ListForm().private bool _isConversionRegistered;Agregue el método siguiente, RegisterTextFieldValueConverters, al archivo, dentro del bloque de código (delimitado por llaves de abertura y de cierre) que implementa la clase parcial ListForm.
private void RegisterTextFieldValueConverters() { Converter.RegisterEditFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); Converter.RegisterNewFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); }Este método simplemente llama a los métodos de registro correspondientes de la clase Converter. Se supone que este código tiene la clase personalizada que contiene a las funciones get y set creadas en el procedimiento anterior que se llama "ContosoConverter". Si especificó un nombre diferente para su clase, cambie el código aquí según corresponda.
Modifique la implementación del controlador de eventos OnNavigatedTo en el archivo agregando una comprobación del valor de la marca _isConversionRegistered y una llamada a la función RegisterTextFieldValueConverters agregada en el paso anterior. El controlador de modificación debe ser como sigue.
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; } }Guarde el archivo.
Tenga en cuenta que las funciones de conversión de datos se registran para todos los campos asociados con un tipo de datos Text en los formularios Nuevo y Edición. Es por este motivo que las funciones get y set implementadas para la clase ContosoConverter creada en el procedimiento anterior incluyen comprobaciones condicionales para procesar los datos para un campo en particular únicamente (llamado, en este caso, "Contact_x0020_Number"), permitiendo que los datos "pasen a través" para otros campos Text.
Lógica de conversión personalizada para aprovisionar tipos de campo no admitidos
Incluso si no proporciona lógica de conversión en su aplicación para campos Text, aún es posible mostrar y editar dichos campos. Si proporciona su propia lógica de conversión para campos que ya cuentan con lógica de conversión predeterminada, puede tener más control sobre el formato o la estructura de los datos en dichos campos si la lógica predeterminada no es apta para los objetivos de su diseño. Para campos con otros tipos específicos de datos, como campos Guid, la lógica de conversión no se proporciona de forma predeterminada, pero si usted comprende el mecanismo (descrito en la sección anterior) con el que se proporciona lógica de conversión para campos, puede resultarle bastante sencillo proporcionar su propia lógica de conversión para admitir tipos de campo en su aplicación que la plantilla Aplicación de lista de SharePoint para Windows Phone no admite con lógica predeterminada.
Suponga que está creando una aplicación de Windows Phone basada en una lista de SharePoint con el nombre Identificadores de productos, que incluye un campo con un tipo de datos Guid. A los fines de la siguiente muestra de código, suponga que la lista tiene un campo Product (o Title) (de tipo Text) y un campo Identificador (de tipo Guid).
Nota:
[!NOTA] Las listas de SharePoint con campos Guid deben crearse con programación o a partir de una plantilla de lista que incluye los campos Guid.
En una aplicación de Windows Phone creada con la plantilla y basada en esta sencilla lista, los datos en los campos Guid no se muestran de forma predeterminada. (En lugar de esos datos, se mostrará un mensaje como el siguiente: "No se registra ningún convertidor para el tipo de campo 'Guid'"). En el procedimiento siguiente, incluirá lógica de conversión para admitir campos Guid para una aplicación de Windows Phone. Agrega una clase que contiene métodos para registrar convertidores de valores de campo a fin de visualizar los GUID y generar nuevos valores de GUID para elementos de lista agregados.
Para proporcionar lógica de conversión para un tipo de campo no admitido
En un proyecto (llamado, por ejemplo, SPListAppGuidConversion) creado desde la Aplicación de lista de SharePoint para Windows Phone y basado en los Identificadores de productos mencionados más arriba, elija el nodo que representa al proyecto en el Explorador de soluciones.
En el menú Proyecto, elija Agregar clase. Aparece el cuadro de diálogo Agregar nuevo elemento con la plantilla Clase de C# ya seleccionada.
Especifique GuidConversion.cs como nombre del archivo y elija Agregar. De esta manera, el archivo de clase se agrega a la solución y queda abierto para modificación.
Cambie el contenido del archivo por el siguiente código.
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; } }); } } }En esta clase personalizada, a los métodos RegisterDisplayFieldValueConverter y RegisterNewFieldValueConverter de la clase Converter se los llama con funciones anónimas (definidas por una instrucción lambda) para implementar las rutinas get y set para los delegados necesarios por los métodos de registro. Las etiquetas de argumentos opcionales aquí (por ejemplo, "getConvertedFieldValue:") se incluyen en este código únicamente para clarificar qué delegados se definen).
Este enfoque, que implica expresiones lambda, es una alternativa a pasar funciones con nombre como parámetros a las funciones de registro de convertidor, lo que se demostró en un procedimiento anteriormente descrito en este tema (en esta sección Para registrar las funciones de conversión de datos).
Guarde el archivo.
En el Explorador de soluciones, elija el nombre del archivo App.xaml.
PresioneF7para abrir y editar el archivo asociado que contiene código, App.xaml.cs.
Ubique la implementación del controlador de eventos Application_Launching (que está vacía en una nuevo proyecto creado desde la plantilla Aplicación de lista de SharePoint para Windows Phone) y reemplácela con el siguiente código.
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(); }Para que la lógica de convertidor funcione con nuevos elementos de lista (o sea, para generar valores de GUID cuando se agregan elementos a la lista), necesita asegurarse de que el campo Identificador del NewItemViewModel está enlazado al formulario Nuevo. Una manera de hacer esto es al agregar un control TextBlock oculto a NewForm.xaml con una declaración Binding para su propiedad Text establecida en el campo Identificador. Puede agregar el control TextBlock al control de contenedor StackPanel que incluye al control TextBox para el campo Título, como en la siguiente sección del marcado en el archivo 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>Guarde el archivo.
Si usted empieza el proyecto e implementa la aplicación en el Emulador de Windows Phone para iniciarla, los datos del campo Identificador se muestran en el formulario Lista (List.xaml) si el campo correspondiente de la lista de SharePoint contiene un valor GUID. (Vea la Figura 1.)
Figura 1. Visualización de campos Guid
En proyectos basados en la plantilla Aplicación de lista de SharePoint para Windows Phone, los controles de Silverlight no pueden agregarse a formularios y enlazarse a tipos de campo que no se admiten con lógica de conversión predeterminada en la plantilla. Para el campo Identificadores de la lista Identificadores de producto usada en el procedimiento anterior, podría agregar marcado al archivo DisplayForm.xaml para definir controles adicionales y visualizar valores GUID, como un control TextBlock y un control TextBox en un control StackPanel, que está contenido dentro del control Grid de la interfaz de usuario. El marcado para el control StackPanel agregado podría tener el siguiente aspecto.
<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>
Ahora el campo Identificador se muestra en el formulario Visualización al igual que el formulario Lista.