SharePoint 2010: Eventos disponibles en listas, sitios y flujos de trabajo!

Otra de las novedades de SharePoint 2010 es la relativa al modelo de eventos que ha sido completamente re-hecho y se soportan más eventos añadidos a los disponibles en SharePoint 2007:

  • FeatureUpgrading.
  • WebAdding.
  • WebProvisioned.
  • ListAdding.
  • ListAdded.
  • ListDeleting.
  • ListDeleted.
  • WorkflowStarting.
  • WorkflowStarted.
  • WorkflowPostponed.
  • WorkglowCompleted.

Otra novedad importante es que con Visual Studio 2010 (VS 2010) se simplifica el proceso de creación de un evento ya que disponemos de una plantilla de proyecto para crear dichos eventos:

  • En VS 2010 dispondremos de la plantilla Event Receiver para crear estos elementos. Al seleccionar esta plantilla se inicia un asistente que nos irá guiando en la creación del evento.
  • En la primera pantalla del asistente, especificamos la url del sitio de SharePoint 2010 en el que queremos depurar el Event Receiver y el modo de despliegue. Fijaros que se puede desplegar en modo Sandbox o en modo Full Trust. Si lo desplegamos en modo Sandbox, aparecerá en la galería User code solutuion (Por lo tanto, aquí tenemos otro artefacto más que tiene pinta que se podrá desplegar en SharePoint Online v 2.0…veremos en que queda la cosa). si lo desplegaos en modo Full Trust, aparecerá como una feature.
  • En la siguiente pantalla, podemos ver la categoría de eventos disponibles y los eventos por categoría: List Events, List Item Events, List Email Events, Web Events y List Workflow Events
image image  image
  • Por ejemplo, en la categoría List Workflow Events podemos ver alguno de los eventos nuevos que vienen con SharePoint 2010.
  • Fijaros además que para los eventos de lista, podremos escoger el tipo de lista al que vincular el Event Receiver.
  • Además, podremos elegir más de un evento por categoría.
  • En mi caso, voy a elegir un evento de la categoría List Item Events y en concreto el evento An Item is being deleted para una lista de tipo Tasks.
  • Tras pulsar Finish en el asistente, se creará la estructura de proyecto del Event Receiver (típica de un artefacto de SharePoint 2010 en VS 2010).
image image image
  • El siguiente paso consiste en añadir el código asociado al tipo de evento seleccionado utilizando para ello la vista de código del elemento de tipo Event Receiver. Por ejemplo:

       public override void ItemDeleting(SPItemEventProperties properties)

       {

           if (properties.ListItem["Status"].ToString()!="Completed")

           {

               properties.Cancel = true;

               properties.ErrorMessage = "Sorry " +

                   properties.UserDisplayName +

                   " this task cannot be deleted because is not completed";

           }

       }

  • Tras compilar el código, no tenemos más que desplegarlo en el sitio elegido. El despliegue es tan simple como seleccionar el nombre del proyecto, hacer clic con el botón derecho del ratón y pulsar la opción Deploy.
  • Lo siguiente que haremos es comprobar que el manejador desplegado funciona de forma correcta. Para ello, intentamos borrar una tarea con la columna Status con el valor Completed.
  • Lógicamente, como se cumple la condición que hemos puesto en el código del manejador, el usuario será redirigido a la correspondiente página de error de SharePoint personalizada con el mensaje que hemos añadido en el código. En cambio, si tratamos de borrar una tarea con otro estado, esta se borrará sin problemas.
image image

Y hasta aquí llega este primer post sobre eventos y manejadores de eventos en SharePoint 2010. Espero que el post os haya resultado interesante.

SharePoint 2010: Ejemplos en MSDN Code Gallery!

El equipo de documentación de SharePoint ha decidido que se irán publicando ejemplos sobre desarrollo en SharePoint 2010 en MSDN Code Gallery en lugar de tener que esperar a que dispongamos del SDK. En mi opinión, es una decisión muy acertada ya que dispondremos de dichos ejemplos sin tener que esperar a que se vayan liberando versiones del SDK. Estos ejemplos aparecerán como porte de la RTM del SDK. Os dejo los primeros proyectos que se han ido publicando:

Versiones_SharePoint_2010

SharePoint 2010: Mejoras en Usabilidad (I)!

De cara al usuario final, SharePoint 2010 se ha diseñado pensando en qué el usuario sea lo más productivo posible en el uso de la plataforma. Por eso se han introducido mejoras notables que se irán conociendo durante los próximos meses como:

  • La incorporación de la Ribbon de Office 2007 a la UI de SharePoint 2010 con el objetivo de reducir el número de clics necesarios para operar de forma eficiente con SharePoint 2010.
  • Un nuevo sistema o framework de ventanas modales, que no deja de ser un DIV flotante, que permite que las típicas operaciones de edición, visualización o creación se realicen sin tener que hacer transiciones entre páginas. Así, si editamos estamos trabajando con una lista de SharePoint a través de la Ribbon y el sistema de ventanas modal nos permitirá simplificar notablemente el trabajo con la misma:
    • Así, si lo que vamos a hacer es crear un nuevo elemento en la lista, veremos que la Ribbon nos ofrece sólo la opción de crear un único elemento.
    • Si seleccionamos un elemento existente, veremos que automáticamente tendremos más operaciones disponibles: visualización, edición y borrado del elemento, gestión de permisos, etc.
    • Si editamos el elemento, aparece la ventana modal comentada.
image image Work_With_List_3
    • Si nos vamos a la pestaña Share & Track, podremos realizar operaciones tan habituales con listas como subscribirnos vía RSS, crearnos alertas, …

image

    • Si volvemos a la pestaña List Tools y nos centramos en la subpestaña List, podremos realizar operaciones a nivel de lista como añadir una nueva columna, crear vistas sobre la lista o personalizar los formularios de lista. En el caso de SharePoint Foundation 2010, la personalización de dichos formularios se puede realizar a través de la UI o SharePoint Designer 2010. En el caso de SharePoint Server 2010, el nuevo Infopath Designer 2010 (ya veremos otro post sobre esto) se convierte en la herramienta de personalización y diseño de formularios de lista. Volviendo a los formularios de lista de SharePoint Foundation 2010, tendremos la posibilidad de configurar mínimamente dichos formularios a través de la Ribbon y también las Web Parts que incluyan.

image image image

  • Completo soporte de AJAX, lo que evita recargas innecesarias en las páginas de SharePoint 2010. Además, toda Web Part se puede configurar para que tenga habilitado AJAX o no.
  • Y la última de momento, si por lo que sea tu sito de SharePoint 2010 no carga debido a algún problema de rendimiento, ya no es necesario recargar la página. Basta con cerrar el error para que se inicié de nuevo la carga del sitio…cool!
image Tratamiento_Errores_2

Y hasta aquí llega este primer post sobre usabilidad en SharePoint 2010.

SharePoint 2010: El # de BD’s ha crecido como las setas…y lo que queda!

Otra de las novedades de SharePoint 2010 es que desaparece el concepto de Shared Services Provider (SSP) que teníamos en MOSS, de manera que hablamos de aplicaciones de servicios al “servicio” de las aplicaciones web de SharePoint. Cada aplicación web en SharePoint se puede asociar a 1 o n aplicaciones de servicios. Además, esta idea no es exclusiva de SharePoint Server 2010, sino que aparece también en Microsoft SharePoint Foundation 2010. Precisamente, una de las consecuencias que tiene el que pasemos de SSP a aplicaciones de servicio es que el # de BD’s crece y mucho. En la CTP de Julio de 2009 de SharePoint 2010 tenemos las siguientes aplicaciones de servicios:

  • Business Connectivity Services y Usage and Health Data Collecion en Microsoft SharePoint Foundation 2010.
  • En el caso de SharePoint Server 2010, tenemos que añadir a los anteriores al menos 9 servicios (en la instalación que tengo en la CTP de Julio en la que no tengo configuradas las búsquedas, no tengo Gemini, PerformancePoint, Visio Services, Access Services, …vamos que a SharePoint 2010 le han crecido los servicios :P).
image image image

Y como os decía, el # de BD’s crece y mucho…y aquí va la prueba:

image image

Veremos finalmente con la RTM como queda la cosa ;-).

SharePoint 2010: Trabajo con LINQ To SharePoint (I)!

Otra de las novedades más esperadas dentro de la plataforma SharePoint es el soporte de LINQ para realizar consultas de listas de SharePoint. En SharePoint 2010 aparece LINQ To SharePoint, que permite realizar consultas LINQ de información almacenada en la plataforma de una forma más clara, sencilla de comprender, acceso a datos fuertemente tipado y a un nivel de abstracción superior. Como sabéis, si trabajamos con LINQ To SQL o ADO.NET Entity Framework, al realizar una consulta LINQ por debajo tendremos un objeto (DataContext y ObjectContext) respectivamente que se encarga de enviar el correspondiente T-SQL a la BD subyacente. En el caso de SharePoint el objeto DataContext correspondiente es el que se encarga de generar y realizar la consulta CAML que se corresponde con la consulta LINQ definida. En este primer post sobre LINQ To SharePoint, vamos a realizar una sencilla consulta LINQ  a una lista personalizada de SharePoint. Empecemos. (Nota: Todo lo que veáis aquí de SharePoint 2010 tiene que ver con la CTP de julio. La versión de Visual Studio 2010 utilizada es la Ultimate Beta2).

Generación de la clase proxy de LINQ To SharePoint para acceder a los datos

En el ejemplo que voy a realizar, vamos a acceder a una lista personalizada denominada Products que tiene dos únicas columnas. Para acceder a los datos de la lista vía LINQ To SharePoint, lo primero que tenemos que hacer es generar la correspondiente clase proxy que nos permita conectarnos a la misma. Para ello, y con la CTP de julio de SharePoint 2010 tenemos que utilizar la utilidad SPMetal que se encuentra en la siguiente ruta:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin

Una vez situados en dicho path, para generar la clase proxy para poder acceder a los datos de una lista de un sitio…y en general a todo el sitio, ejecutamos el siguiente comando:

spmetal /web:http://win-lpgjegdoo6f /namespace:Intranet /code:Intranet.cs

Cómo veis, en la sintaxis de spmetal:

  • En primer lugar especificamos la url del sitio de SharePoint en el que vamos a generar la clase proxy. Para ello utilizamos el parámetro web.
  • A continuación mediante el parámetro namespace especificamos el espacio de nombres a usar en la clase proxy a generar.
  • Finalmente el parámetro code nos permite especificar el nombre del archivo de C# generado.
image image image

Si ejecutamos el comando anterior, transcurridos unos segundos tendremos la clase proxy lista para ser utilizada en VS 2010 Beta2. Si queréis ver las opciones de ejecución de SPMetal, basta conque lo ejecutéis tal cual para ver los parámetros de que dispone y algunos ejemplos de sintaxis.

Creación de la WebPart de visualización

Para mostrar los datos devueltos por la consulta LINQ To SharePoint que voy a definir, voy a utilizar las Visual Studio Tools para SharePoint 2010, y en concreto la posibilidad que nos brinda de crear Web Parts visuales para facilitar su desarrollo:

  • Arrancamos Visual Studio 2010 Beta 2, y nos vamos a crear un proyecto para SharePoint 2010 de tipo Visual Web Part.
  • Tras pulsar OK, nos llevamos la primera en la frente: aparece un mensaje de error diciéndonos que no es posible crear el proyecto porque se necesita SharePoint Server instalado en el servidor…toma ya…lógicamente me quedo sorprendido porque en mi máquina virtual tengo instalada la CTP de julio de SharePoint Foundation 2010 y desde luego no me esperaba este resultado. Aunque he de decir que no me sorprende, recuerdo que algo parecido sucedió con la plantilla de creación de workflows para SharePoint 2007 que apareció con Visual Studio 2008. Seguro que en breve a alguien se le ocurre como solucionar esta cag…digo este problemilla.
image image image

Por suerte, parece que los proyectos creados para SharePoint 2010 con la Beta1 de las Visual Studio Tools para SharePoint 2010 funcionan con la Beta2 y me las arreglé para conseguir el resultado esperado. Si no hubiera sido por el inconveniente anterior, al pulsar OK en le proyecto se inicia un asistente en el que se nos pie el sitio de SharePoint que se va a utilizar para depurar la solución y el modo de despliegue de la misma (que para una Web Part visual es Full Trust al menos en la CTP de julio de SharePoint 2010):

Visual_Studio_SharePoint_Tools_6

Como os decía, para superar el inconveniente anterior probé a abrir un proyecto ya creado con la Beta 1 de Visual Studio 2010 y esta vez, para mi sorpresas, no hubo ningún problema. En VS 2010, la estructura típica de un proyecto para SharePoint 2010 se caracteriza por los siguientes elementos:

  • El grupo de ítems particulares correspondientes a la plantilla elegida. En este caso se trata de una Web Part Visual que no es más que está representado por tres elementos:
    • El primero de ellos tiene la extensión .WebPart y nos permitirá parametrizar ciertas configuraciones de la Web Part Visual como su título, descripción. 
    • El segundo de los elementos es un archivo .cs en el que se definen los métodos clásicos (este trabajo lo hace Visual Studio) para renderizar la Web Part en la UI de SharePoint: CreateChildControls() y Render().
    • Finalmente, el último de los elementos es un user control (extensión .ascx) y es el que nos permite modelar visualmente la Web Part y añadirle la lógica correspondiente en el archivo de código asociado.
  • Una sección Package o paquete en la que se “empaquetan” las distintas features o características que contiene la solución. En este caso concreto sólo tendremos una única feature. Como podéis ver, configurar un package se simplifica bastante gracias al nuevo diseñador que incluye las VS Tools. Comentaros que dado un proyecto de SharePoint 2010, sólo puede contener un único paquete.
  • Una sección Features en la que tendremos todas las características del proyecto actual. En este caso tendremos una única característica, pero podríamos tener tantas como elementos de SharePoint añadamos al proyecto: manejadores de eventos, flujos de trabajo, etc. De nuevo, la gestión de las características se simplifica notablemente gracias al nuevo diseñador incorporado en VS 2010. A su vez, cada característica puede contener los elementos del proyecto que necesitemos.
image image image

Una vez explicados estos detalles generales de estructura de un proyecto de SharePoint, vamos al lío: a trabajar con la Web Part visual:

  • Lo primero y más importante, podemos diseñar la Web Part de forma visual o a “pelo” trabajando con el markup. En mi caso he hecho uso de las dos cosas, porque por un lado voy a utilizar un control de SharePoint de tipo SPGridView y por otro lado una simple etiqueta.
  • El markup necesario para una web part tan sencilla es el siguiente:

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>

<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1UserControl.ascx.cs" Inherits="SPLinqDemo.VisualWebPart1.VisualWebPart1UserControl" %>

<%@ Import Namespace="Microsoft.SharePoint.WebControls" %>

<SharePoint:SPGridView ID="spGriedView" runat="server" AutoGenerateColumns="false">

    <HeaderStyle HorizontalAlign="Left" ForeColor="Navy" Font-Bold="false" />

    <Columns>

        <SharePoint:SPBoundField DataField="Title" HeaderText="Title" HeaderStyle-HorizontalAlign="Center">

        </SharePoint:SPBoundField>

                <SharePoint:SPBoundField DataField="Amount" HeaderText="Amount" HeaderStyle-HorizontalAlign="Center">

        </SharePoint:SPBoundField>

</Columns>

</SharePoint:SPGridView>

<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

  • Visualmente podéis ver que el diseñador no es capaz de interpretar el control SPGridView ya que no forma parte de la paleta de controles disponible para SharePoint en el diseñador, aunque esto no supondrá problema alguno en la creación de la WebPart.
  • Lo siguiente que tenemos que hacer es añadir a nuestro proyecto la clase proxy generada con SPMetal. Os recomiendo revisar lo que ha generado con SPMetal…aunque quizás hasta la RC o RTM es mejor no hacerle mucho caso porque seguramente falten elementos por generar (lo digo con conocimiento :P). Básicamente, la clave es que tendremos una clase que deriva Microsoft.SharePoint.Linq.DataContext y que es la que se encarga de gestionar las conexiones a las diferentes listas de SharePoint. Para cada lista, se habrá generado el correspondiente EntityList.
  • Una vez hecho esto, añadimos una referencia al ensamblado Microsoft.SharePoint.dll ubicado en el path:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

  • Nos vamos a la vista de código del control de usuario vinculado a la Web Part Visual y añadimos las siguientes directivas using:

using System.Linq;

using Intranet;

using Microsoft.SharePoint;

using Microsoft.SharePoint.Linq;

  • En el evento Page_Load() del control añadimos el siguiente código:

            try

            {

                IntranetDataContext dc =

                     new IntranetDataContext(SPContext.Current.Web.Url);

 

                var ListData = from an in dc.Products

                               select new { an.Title, an.Amount };

 

                this.spGriedView.DataSource = ListData;

                this.spGriedView.DataBind();

                this.Label1.Text = "";

 

            }

            catch (Exception ex)

            {

               

                this.Label1.Text=ex.Message;

            }

 

  • Cómo veis, trabajar con LINQ To SharePoint es similar a como se trabaja con el resto de sabores de LINQ To “Algo”:
    • En primer lugar, tenemos que crear una instancia del objeto DataContext correspondiente y que se haya definido en la clase proxy generada por SPMetal.
    • A continuación, definimos la consulta LINQ correspondiente.
  • Compilamos el código para asegurarnos que no hay errores.
  • Para desplegar la Web Part, basta con hacer clic con el botón derecho del ratón en el nombre del proyecto y pulsar Deploy, con lo que ya la tenemos lista la Web Part para usar en SharePoint.
image   LINQ_To_SharePoint_5_Beta2

Despliegue de la Web Part en SharePoint

Finalmente, vamos a desplegar la Web Part en un sitio de SharePoint existente. En mi caso, la voy a desplegar en una página de Web Parts almacenada en una biblioteca de documentos:

  • Navegamos hasta la página en cuestión.
  • A través de la nueva Ribbon de SharePoint 2010, editamos la Web Part.
  • Seleccionamos una zona de Web Parts en la que insertar la que acabamos de crear. De esta forma, aparece en la Ribbon una pestaña Insert.
  • En la pestaña Insert, seleccionamos Web Part de manera que se muestra justo encima de nuestra página la nueva área de insercción de Web Parts que incorpora SharePoint 2010.
  • Nos vamos a la categoría Custom dentro de listado de Web Parts disponibles y seleccionamos nuestra Web Part.
LINQ_To_SharePoint_6_Beta2 LINQ_To_SharePoint_7_Beta2 LINQ_To_SharePoint_8_Beta2
  • Pulsamos Add y listo, ya tenemos la Web Part de LINQ To SharePoint operativa.
LINQ_To_SharePoint_9_Beta2 LINQ_To_SharePoint_10_Beta2

Y hasta aquí llega este primer post sobre LINQ To SharePoint. Espero que os haya resultado interesante.