SharePoint 2010: ¿Como cambiar / ocultar la columna Título en mis tipos de contenido?

Cómo sabéis, en SharePoint todo tipo de contenido (CT) hereda de un tipo padre. En el caso de CTs de listas, normalmente el tipo de contenido padre definido en la raíz de la jerarquía es “Item” y es aquí dónde se define la famosa columna “Title” o “Título” que tenemos en cualquier lista personalizada. Una pregunta que me han hecho hace poco es como cambiar el nombre para mostrar de esa columna o incluso ocultarlo…la respuesta es qué depende de dónde lo hagamos,

  • Si lo hacemos a nivel de interfaz de usuario, como “Title” es una columna de sitio implicaría que un cambio de nombre afectaría a todo CT en el qué se esté usando por lo que la alternativa aquí pasa por ocultar la columna y no usarla en nuestros formularios.
  • Para ello, nos vamos a la definición del CT en la galería de tipos de contenido del sitio y en la página de detalle pulsamos sobre la columna “Title”. En la página que se abre, simplemente marcamos la columna como oculta y listo.
  • Probamos en una lista en la que usemos el tipo de contenido que el cambio es efectivo…aquí tenéis que tener cuidado, ya que si el tipo de contenido antes de los cambios se había usado (por ejemplo, se habían creado elementos de lista), posiblemente tengáis errores en su uso debido a que la actualización de los cambios en el tipo no se han propagado a las listas.
image image image
  • La segunda opción disponible pasaría por usar SharePoint Designer 2010 (SPD 2010) para realizar el mismo tipo de cambio que hemos realizado en la interfaz de usuario.
  • La tercera opción, y recomendable, es usar la aproximación declarativa para definir el tipo de contenido y configurar a la carta las columnas que forman parte del mismo…tanto las heredadas, como las que añadamos. Por suerte, con Visual Studio 11 Beta (VS 11 Beta), realizar estas configuraciones es bastante sencillo.
  • Si cambiamos el nombre en el diseñador de CTS de VS 11 Beta, se actualizará la correspondiente definición.
image image
  • De manera que antes del cambio, dicha definición es de la forma:
   1: <?xml version="1.0" encoding="utf-8"?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <!-- Parent ContentType: Item (0x01) -->

   4:   <ContentType ID="0x0100F09DE7082513424993A7A91D901E1241" Name="SPO Sample CT" Group="Custom Content Types" Description="SPO Sample CT" Inherits="TRUE" Version="0">

   5:     <FieldRefs>

   6:       <FieldRef ID="{82642ec8-ef9b-478f-acf9-31f7d45fbc31}" DisplayName="$Resources:core,Title;" Required="TRUE" Name="LinkTitle" ReadOnly="TRUE" />

   7:       <FieldRef ID="{575daf36-dbae-46a9-a8c3-1d269004a85e}" DisplayName="SPO Site Column" Required="TRUE" Name="VS11SPOSiteColumnSample" />

   8:     </FieldRefs>

   9:   </ContentType>

  10: </Elements>

  • Y tras el cambio pasa a:
   1: <?xml version="1.0" encoding="utf-8"?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <!-- Parent ContentType: Item (0x01) -->

   4:   <ContentType ID="0x0100F09DE7082513424993A7A91D901E1241" Name="SPO Sample CT" Group="Custom Content Types" Description="SPO Sample CT" Inherits="TRUE" Version="0">

   5:     <FieldRefs>

   6:       <FieldRef ID="{82642ec8-ef9b-478f-acf9-31f7d45fbc31}" DisplayName="Otro nombre" Required="TRUE" Name="LinkTitle" ReadOnly="TRUE" />

   7:       <FieldRef ID="{575daf36-dbae-46a9-a8c3-1d269004a85e}" DisplayName="SPO Site Column" Required="TRUE" Name="VS11SPOSiteColumnSample" />

   8:     </FieldRefs>

   9:   </ContentType>

  10: </Elements>

  • Cómo veis, el cambio consiste en cambiar la propiedad DisplayName en el elemento <FieldRef que hace referencia a la la columna Title…la referencia se mantiene, pero el nombre para mostrar se ha cambiado.
  • Finalmente, la cuarta opción que tenemos para realizar cambios de este tipo es mediante el uso del modelo de objetos de SharePoint. En concreto, si usamos SPField podremos cambiar el nombre para mostrar a través de la propiedad Title de esta clase.

¡Seminarios y Eventos de junio en el CIIN, no te los pierdas…Windows 8 is coming ;-)!

Desde el Centro de Innovación en Integración (CIIN), seguimos trabajando para dar a conocer las nuevas tecnologías y las herramientas necesarias para trabajar con ellas. Por eso, para las próximas semanas hemos programado varias actividades que giran alrededor fundamentalmente en torno Windows Phone y Windows 8, y por supuesto en trono a SharePoint 2010, Office 365 y Windows Azure.

Por eso, para este mes de junio tenemos preparada una agenda con una serie de eventos que esperamos sean de tu interés comenzando con la participación en el roadshow de soluciones de negocio con SharePoint organizado por AvePoint, para a continuación seguir con dos jornadas sobre desarrollo para Windows Phone 7 en la que de la mano de José Antonio Gallego veremos desde como desarrollar una sencilla aplicación para el s.o móvil de Microsoft hasta como podemos portarla a la nueva versión de Windows que llegará tras el verano: Windows 8. Finalmente, no te puedes perder el primer evento para desarrolladores en Windows 8 en Cantabria que realizaremos la última semana de junio en colaboración con Rafael Serna (SDM Programas) y Josué Yeray (Plain Concepts)

Resumen de eventos:

Esperamos que estos seminarios y eventos sean de tu interés y te dejes caer por alguno de ellos.

logoCIIN_GIF_Comprimida

SharePoint 2010: Soporte de virtualización!

Simplemente como referencia, y para aclarar dudas al respecto, si estás pensando en hacer un despliegue de SharePoint 2010 completamente virtualizado, que no os tiemblen las piernas porque SharePoint 2010 tiene pleno soporte para despliegues en los que se quiera virtualizar todos sus componentes incluyendo los servidores de base de datos. Podéis encontrar información relativa a este soporte en los siguientes enlaces:

SharePoint2010_thumb

SharePoint 2010 y Azure: Integración con el Windows Azure Data Market (III)!

Siguiendo con la serie de posts sobre la integración de SharePoint y el Windows Azure Data Market, vamos a cerrar el círculo y ver como otra posibilidad de integración pasa por crear vistas de datos usando SharePoint Designer 2010 (SPD 2010). Os recuerdo antes los artículos previos de la serie:

Lo interesante de esta aproximación es que nos permite integrar datos del Windows Azure Data Market tanto en SharePoint 2010 On-Premise como en SharePoint Online (SPO) en Office 365. Para crear una vista de datos a partir de una fuente disponible en el Windows Azure Data Market:

image image image
  • De esta forma automáticamente tenemos una primera vista de datos disponible en la página y el panel de origen de datos que usaremos a continuación para generar la vista como queremos escogiendo los campos de información necesarios.
  • Eliminamos la vista que añade SPD 2010, escogemos los campos que queremos que formen parte de la vista y los arrastraos a la zona de WebParts de la página.
  • En la cinta de configuración de la vista de datos, pulsamos sobre “Add/Remove Columns” para añadir nuevas columnas y/o ordenar las columnas existentes.
image image image
  • Guardamos los cambios y previsualizamos la vista en el explorador. Y listo.

image

SharePoint 2010: Como ocultar una acción de la Ribbon!

A raíz de una consulta relativa a si era posible ocultar una acción de la cinta usando un Security Trimmed Control me puse a explorar que posibilidades hay en SharePoint 2010 más allá de la aproximación declarativa que se comenta en este artículo. Otras posibilidades que tenemos pasan por hacerlo de forma programática a través de:

SharePoint2010_thumb

SharePoint Online: Integración de SQL Azure!

Si os estáis preguntando si a día de hoy alguna forma de integrar datos de SQL Azure en SharePoint Online (SPO), la respuesta es que sí…y no pasa por el uso de los BCS (que aunque inicialmente si permitía crear tipos de contenido externo para BD’s SQL Azure, actualmente no se soporta), sino por usar la versátil Data Form WebPart que a partir de definir un origen de datos basado en SQL Azure nos deja crear vistas de datos en base a dicha fuente. Esto ya lo expliqué hace unos meses para SharePoint 2010 On-Premise y es igual de válido para SPO en Office 365. Podéis ver la mecánica de integración en este enlace.

image

SharePoint 2010 y Azure: Integración con el Windows Azure Data Market (II)!

Siguiendo con la serie de posts sobre como integrar Windows Azure Data Market y SharePoint 2010, en esta ocasión vamos a ver como podemos realizar dicha integración a través de un Business Data Connectivity Model o simplemente un conector de BCS (Business Connectivity Services) que crearemos en Visual Studio 11 Beta (VS 11 Beta) y que luego desplegaremos en nuestro ambiente de SharePoint. Empecemos:

  • Lo primero que tenemos que hacer como siempre es conocer la forma que tenemos de integrar la fuente de datos del Windows Azure Data Market. En mi caso, voy a trabajar con el set de datos 2006 – 2008 Crime in the United States que se puede integrar de forma muy sencilla en nuestras aplicaciones sin más que añadir una referencia al correspondiente servicio que en este caso es: https://api.datamarket.azure.com/data.gov/Crimes/
  • Como siempre, antes de ponernos a  hacer nada podemos jugar con el set de datos directamente desde el Data Market.
  • En VS 11 Beta creamos un proyecto de tipo SharePoint 2010 Project al que añadimos un elemento de tipo Business Data Connectivity Model que pasaremos a parametrizar a continuación. Este modelo tendrá una única entidad, Crime, que nos permitirá acceder a la información de los crímenes que expone el servicio.
image image image
  • En lugar de trabajar con el diseñador del Business Data Connectivity Model, vamos a agregar en primer lugar la lógica necesaria para acceder a los datos del servicio. Para ello, añadimos en primer lugar una referencia al citado servicio en nuestro proyecto. Tendremos que añadir además una referencia a System.Data.Services.Client.
  • A partir de aquí, en el explorador de soluciones vamos a preparar las dos clases que se crean al añadir el elemento de tipo Business Data Connectivity Model al proyecto: Entity1 y Entity1Service. La primera clase modela la entidad tipo que nos permite integrar los datos del servicio en SharePoint a través de una serie de propiedades. La segunda, contiene los métodos que permiten trabajar con entidades de tipo Entity1.
  • En mi caso, he renombrado Entity1 a Crime y le he añadido las siguientes propiedades que luego se mapearán a propiedades del set de datos expuestos por el servicio:
   1: public partial class Crime

   2: {

   3:     //TODO: Implement additional properties here. The property Message is just a sample how a property could look like.

   4:     public int ID { get; set; }

   5:     public string State { get; set; }

   6:     public string City { get; set; }

   7:     public int Year { get; set; }

   8:     public int Population { get; set; }

   9:     public int Burglary { get; set; }

  10:     public int LarcenyTheft { get; set; }

  11:     public int MotorVehicleTheft { get; set; }

  12: }

  • A continuación iremos por la clase Entity1Service que en este caso renombramos a CrimeService. En la misma añadimos referencias a System.Net, System.Data.Services.Clien y al servicio de Windows Azure Data Market.
  • Añadimos a la clase un método que nos permita devolver un proxy al servicio. Como veis, simplemente se trata de devolver dicho proxy y además lidiar con no tener problemas de conexión por SSL usando para ello ServicePointManager y confiando en certificados del Windows Azure Data Market. Este proxy nos permitirá acceder a los datos del servicio.

   1: private static datagovCrimesContainer GetProxy()

   2: {

   3:     ServicePointManager.ServerCertificateValidationCallback =

   4:         ((sender, certificate, chain, sslPolicyErrors) => 

   5:             certificate.Subject.Contains("datamarket"));

   6:     Uri serviceUri =

   7:         new Uri("https://api.datamarket.azure.com/Data.ashx/data.gov/Crimes");

   8:     datagovCrimesContainer proxy =

   9:         new datagovCrimesContainer(serviceUri);

  10:     proxy.Credentials =

  11:         new NetworkCredential("Yor Data Market Account",

  12:             "Your Data Market Key");

  13:     return proxy;

  14:  

  15: }

  • Esta clase al menos tiene que implementar dos métodos:
    • Uno de tipo “Specific finder” que devuelva una entidad de tipo Crime en base a un parámetro como por ejemplo puede ser un identificador. En este caso, el método en cuestión se ha renombrado a ReadCrime. Cómo veis, a partir de un identificador y el proxy podemos acceder fácilmente a un registro expuesto por el servicio y devolverlo.
   1: public static Crime ReadCrime(int id)

   2: {

   3:     datagovCrimesContainer proxy = GetProxy();

   4:  

   5:     var results = from stat in proxy.CityCrime

   6:                   where stat.ROWID == id

   7:                   select stat;

   8:  

   9:     Crime currentStat = new Crime();

  10:  

  11:     currentStat.ID = results.Single().ROWID;

  12:     currentStat.City = results.Single().City;

  13:     currentStat.State = results.Single().State;

  14:     currentStat.Year = results.Single().Year;

  15:     currentStat.Population = results.Single().Population;

  16:     currentStat.Burglary = results.Single().Burglary;

  17:     currentStat.LarcenyTheft = results.Single().LarcenyTheft;

  18:     currentStat.MotorVehicleTheft = results.Single().MotorVehicleTheft;

  19:  

  20:     return currentStat;

  21: }

    • Uno de tipo “finder” que nos devuelva una colección de objetos de tipo Crime. En este caso se ha renombrado el método a ReadCrimes(). Como antes, a partir del proxy es sencillo obtener una colección de objetos CityCrime expuestos por el servicio que luego usaremos para devolver la colección de objetos de tipo Crime.
   1: public static IEnumerable<Crime> ReadCrimes()

   2: {

   3:     List<Crime> queryResults = new List<Crime>();

   4:  

   5:     datagovCrimesContainer proxy = GetProxy();

   6:  

   7:     IEnumerable<CityCrime> crimes = 

   8:         proxy.CityCrime.Where(c => c.State ==

   9:                "Washington" && (c.Year == 2008 || c.Year == 2007));

  10:  

  11:     //Procesando el set de datos devuelto

  12:     foreach (var c in crimes)

  13:     {

  14:         Crime cr = new Crime();

  15:         cr.ID = c.ROWID;

  16:         cr.City = c.City;

  17:         cr.State = c.State;

  18:         cr.Year = c.Year;

  19:         cr.Population = c.Population;

  20:         cr.Burglary = c.Burglary;

  21:         cr.LarcenyTheft = c.LarcenyTheft;

  22:         cr.MotorVehicleTheft = c.MotorVehicleTheft;

  23:  

  24:         queryResults.Add(cr);

  25:     }

  26:  

  27:     return queryResults.ToList();

  28: }

  • A partir de aquí, de vuelta al explorador del modelo de BDC tenemos que configurar adecuadamente la entidad Crime para que se usen estos métodos y tenga los miembros correspondientes de acuerdo a la definición de la clase. Este trabajo lo haremos en el diseñador del modelo y el explorador.
  • En el diseñador configuraremos el nombre de la entidad y de los métodos expuestos. Mientras que en el explorador del modelo configuraremos adecuadamente los parámetros de entrada y de salida de cada uno de estos métodos.
  • Una vez creado el conector, simplemente lo desplegamos y en nuestro sitio de SharePoint creamos la correspondiente lista externa que mostrará los datos expuestos por el servicio.
image image image

 

Y hasta aquí llega este segundo post sobre la integración de SharePoint 2010 y el Windows Azure Data Market.

SharePoint 2010 y Azure: Integración con el Windows Azure Data Market (I)!

Otro gran punto de integración entre SharePoint 2010 y Windows Azure es a través del Windows Azure Data Market de manera que podemos acceder a datos publicados utilizando artefactos de SharePoint como pueden ser WebParts o conectores de BCS. En este primer post os voy a mostrar como podemos usar Bing Translator, que ya está incluido en el Windows Azure Data Market, para poder realizar traducciones en una WebPart. Comencemos:

image image image

Partimos del ejemplo de uso de Microsoft Translator que pasa por descargarse el proxy C# disponible en la página de detalle de Microsoft Translator en el Data Market. A partir de aquí, ya estamos listos para codificar de acuerdo a los siguientes pasos:

  • Agregar referencia a System.Data.Services.Client puesto que los datos del Data Market los consultaremos a través de servicios REST.
  • Añadir directivas using a System.Data.Services.Client, System.Net y el espacio de nombres del proxy que nos hemos bajado (Microsoft en este caso).
  • Especificar la cuenta y clave de uso del Azure Data Market.
  • Evitar el infame error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel, date una vuelta por este enlace para saber de que estamos hablando. Como veis, en mi caso y dado que esto son pruebas uso SharePointManager para saltarme problemas de certificados y dar por válidos los certificados usados por el Azurre Data Market. Si quieres específicamente confiar únicamente en los certificados del Windows Azure Data Market, basta con cambiar que se confía en todos los certificados (valor true) por certificate.Subject.Contains("datamarket").
  • Creamos una instancia del objeto TranslatorContainer definido en el proxy y que nos permite realizar la consulta de traducción.
  • Especificamos la url del servicio de Microsoft Translator y las credenciales de acceso al Windows Azure Data Market.
  • A partir de aquí especificamos que queremos traducir, el idioma de destino y el de origen…realizamos la traducción y procesamos los resultados.
   1: try

   2: {

   3:     this.txtTranslation.Text = "";

   4:     // tUri del Servicio 

   5:     Uri uServiceRootUri =

   6:                    new Uri(

   7:                        "https://api.datamarket.azure.com/Bing/MicrosoftTranslator/");

   8:  

   9:     //  Claves de acceso

  10:     string sAccountUser = "TuCuenta";

  11:     string sAccountKey = "TuClave";

  12:  

  13:     // Objeto Translator Container

  14:     ServicePointManager.ServerCertificateValidationCallback =

  15:         ((MySender, certificate, chain, sslPolicyErrors) => true); 

  16:     TranslatorContainer tc = 

  17:         new TranslatorContainer(uServiceRootUri);

  18:  

  19:     // Credenciales de acceso 

  20:     tc.Credentials = 

  21:         new NetworkCredential(sAccountUser,sAccountKey); 

  22:  

  23:     //*****************************************

  24:     //A traducir

  25:     //*****************************************

  26:  

  27:     // Generamos la consulta 

  28:     var translationQuery = 

  29:         tc.Translate(this.txtWordToTranslate.Text,"en","es");

  30:  

  31:     // Ejecutamos la consulta

  32:     var translationResults = translationQuery.Execute();

  33:  

  34:     // Procesamos los resultados

  35:     if (translationResults!=null)

  36:     {

  37:         foreach (var item in translationResults)

  38:         {

  39:             this.txtTranslation.Text += item.Text;

  40:         }

  41:     }                

  42:  

  43: }

  44: catch (Exception ex)

  45: {

  46:  

  47:     this.lblError.Text = "Error: " +

  48:         ex.Message;

  49: }

Y finalmente la prueba del algodón:

image

Otros posts sobre la integración de SharePoint y Azure:

SharePoint 2010: Tipos de campo soportados como “Projected Fields” al relacionar listas!

Cómo sabéis, en SharePoint 2010 (como en la versión predecesora) es posible relacionar dos listas a través de columnas de tipo búsqueda (Lookup). La novedad que incorporó SharePoint 2010 es que además de relacionar dos listas mediante un campo de búsqueda definido en la lista padre que apunte a una columna de la lista hija, podemos traer columnas adicionales de la lista hija a través de la característica de campos proyectados. Ahora bien, hay que tener en cuenta que no todos los campos definidos en la lista hija pueden ser campos proyectados…en concreto, los siguientes tipo de campos se soportan como proyectados al relacionar dos listas y por ende se pueden usar en consultas CAML definidas a las dos listas:

  • Calculated (treated as plain text).
  • ContentTypeId.
  • Counter.
  • Currency.
  • DateTime.
  • Guid.
  • Integer.
  • Note (one-line only).
  • Number.
  • Text.

Por último, os recomiendo que reviséis la sección de la SharePoint Guidance en la que se tratan estos temas y en los que se resumen de forma muy esquematizada:

  • Como relacionar dos listas mediante campos de lookup.
  • Como se define un campo de lookup en SharePoint 2010.
Ff798514.84ceee0b-1351-487a-a0b6-e10050bb1998(en-us,PandP.10).png Ff798514.ae9fd5b2-ccab-481f-84e2-56d0efeac718(en-us,PandP.10).png

Referencias: