December 2009 - Artículos
Después del primer resumen de los posts que se han escrito en este blog en torno a SharePoint 2010, y para acabar el año con fuerza y comenzar 2010 dando guerra, aquí os dejo el segundo resumen con los últimos posts publicados. Aprovecho el post para desearos a todos una feliz entrada de año, que venga cargado de suerte, éxito y cosas buenas para todos. Nos vemos en 2010 por estos lares.
Capacidades
Business Intelligence
Desarrollo
IT
Recursos
Posts resumen previos
Y hasta aquí llega este segundo resumen de post sobre SharePoint 2010 escritos en este blog.
Estos días me encuentro experimentando algunas de los cambios que aparecen en las características en SharePoint 2010. Estos cambios los tenemos a distintos niveles:
Y hasta aquí llega este primer post sobre novedades en las características en SharePoint 2010.
Siguiendo con la serie de posts sobre la integración de SSRS 2008 R2 y SharePoint 2010, en esta ocasión vamos a ver algunas de las novedades en lo que a creación de informes en el entorno de SharePoint 2010 se refiere. Pero antes de empezar, os recuerdo los dos posts previos de la serie:
SharePoint 2010: Integración con SSRS 2008 y con SSRS 2008 R2 (I)!
SharePoint 2010: Integración con SSRS 2008 y SSRS 2008 R2 (II)!
Creando un informe de SSRS 2008 R2
Como os comentaba en los posts previos, no hay demasiadas ahora mismo no hay demasiadas diferencias en la integración de SSRS 2008R2 con SharePoint 2010 comparado con lo que ya teníamos con SSRS 2008 y SharePoint 2007. Para evaluar las características de la integración:
-
En primer lugar cree una lista de SharePoint 2010 a partir de importar una serie de datos de una hoja de Excel 2010.
-
A continuación cree una biblioteca de documentos que configuré para utilizar el tipo de contenido Report Data Source.
-
A continuación he creado un nuevo elemento en la Biblioteca de tipo Report Data Source.
-
En la ventana de definición de la fuente de datos (de momento no es modal), la primera novedad que nos encontramos es que podemos especificar un sitio o una lista de SharePoint como fuente de datos. En mi caso, al especificar como cadena de conexión la Url del sitio he indicado que quiero utilizar todas las listas y bibliotecas del mismo. Si queréis usar una única lista, tendréis que especificar como cadena de conexión la url de la misma.
-
Fijaros en que el resto de parámetros de la fuente de datos son los clásicos que teníamos en SSRS 2008.
-
De la misma forma, he creado otra Biblioteca para almacenar los informes y la he configurado con el tipo de contenido Report Builder Report.
-
Desde la Ribbon de creación de elementos de la biblioteca, he pulsado sobre Report Builder Report de forma que se ha iniciado el proceso que lanza Report Builder 3.0
-
Una vez que se ha abierto Repot Builder 3.0, nos encontramos con otra novedad: una pantalla inicial que nos permite especificar el tipo de informe a crear a través del correspondiente asistente. Desde esta pantalla podremos crear los tipos de informe:
-
En mi caso he elegido un informe de tipo Table or Matrix.
-
En la primera pantalla del asistente, simplemente tendremos que elegir el Dataset a utilizar o bien crear uno nuevo. En mi caso, la opción es crear uno nuevo.
-
A continuación elegimos la fuente de datos a utilizar para crear el Dataset. En mi caso, he elegido la fuente de datos definida a partir de un sitio de SharePoint 2010.
-
Tras pulsar Next en la pantalla anterior, se muestra una nueva pantalla en la que podemos visualizar todas las listas y bibliotecas del sitio que podemos utilizar para construir nuestro informe.
-
En mi caso, voy a utilizar la lista que creé originalmente con una serie de datos adecuados para crear el informe. De dicha lista he seleccionado los campos relevantes para crear el informe.
-
En la siguiente pantalla del asistente, no tenemos más que configurar los campos a mostrar en el informe de forma adecuada a nuestras necesidades de negocio.
-
En la siguiente ventana dejamos las opciones por defecto que se muestran para seleccionar el layout del informe.
-
A continuación elegimos el estilo para el informe.
-
Tras pulsar Finish, ya tenemos disponible el informe en el diseñador de Report Builder 3.0. A continuación podríamos cambiar el formato del informe a nuestro gusto.
Enlaces de interés sobre los puntos cubiertos en este post:
Y hasta aquí llega este post sobre la integración de SSRS 2008 R2 con SharePoint 2010.
Una de las novedades que incorpora SharePoint 2010 es la posibilidad de gestionar las cuentas manejadas de usuario desde la Administración Central incluso a nivel de cambio de contraseña. Esta gestión la tenéis accesible desde:
-
Dentro de la sección Security de la Administración Central, hacéis clic en Security.
-
En la página que se abre, a través de Configure managed accounts podéis cambiar las configuraciones definidas para las cuentas que estéis usando en SharePoint.
-
En la siguiente página tendremos un listado de las cuentas manejadas disponibles que podemos actualizar con las nuevas configuraciones como puede ser un cambio de contraseña sin tener que abandonar SharePoint.
Más información en el post original de mi blog alternativo en WordPress.
A través del blog de Héctor Insua me he enterado de la existencia de un nuevo proyecto en Codeplex más que interesante para facilitar aún más si cabe el desarrollo para SharePoint 2010: SharePoint 2010 Visual Studio 2010 Extensions. Se trata de un conjunto de plantillas y herramientas para facilitar el desarrollo en la nueva versión de SharePoint.

Otra de las novedades que incorpora SharePoint 2010 es el uso de ventanas modales por todos los lados. Se trata de mejorar la experiencia de usuario en operaciones típicas como la creación de un sitio o de una lista / biblioteca, de un elemento de lista, etc. Estas ventanas modales se basan en el nuevo Framework de ventanas modales que por supuesto podemos usar en nuestros desarrollos para SharePoint 2010.

Para demostraros el uso del nuevo framework de ventanas modales de SharePoint 2010:
- He creado un proyecto de SharePoint 2010 de tipo Empty SharePoint Project.
- En el asistente configuración del proyecto he especificado que la solución a crear se desplegará en modo granja.
- Una vez creado el proyecto, le he añadido la carpeta Layouts al proyecto como carpeta mapeada.
-
Al añadir la carpeta mapeada, dentro de la misma se crea una carpeta con el nombre que le he puesto al proyecto. Esto es así para evitar posibles conflictos con archivos existentes.
-
A continuación he añadido una página de aplicación al proyecto.
|
<asp:Content ID="PageHead" ContentPlaceHolderID="PlaceHolderAdditionalPageHead" runat="server">
<script type="text/javascript">
function OpenDialog() {
var options = SP.UI.$create_DialogOptions();
options.url = "/_layouts/SPDialogsFramework/SampleDialog.htm";
options.width = 400;
options.height = 300;
options.dialogReturnValueCallback =
Function.createDelegate(null, CloseCallback);
SP.UI.ModalDialog.showModalDialog(options);
}
function CloseCallback() {
alert('Has pulsado OK');
}
</script>
</asp:Content>
<asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">
<input type="button" value="Mostrar Diálogo" onclick="OpenDialog()" />
</asp:Content>
<asp:Content ID="PageTitle" ContentPlaceHolderID="PlaceHolderPageTitle" runat="server">
Mostrar Diálogo Modal
</asp:Content>
<asp:Content ID="PageTitleInTitleArea" ContentPlaceHolderID="PlaceHolderPageTitleInTitleArea" runat="server" >
Framework de ventanas modales
</asp:Content>
|
-
Como podéis ver en el código anterior:
-
He añadido en el Place Holder de la cabecera de la página un bloque de código JavaScript que se encarga de mostrar la ventana modal a través de la función OpenDialog(). Esta función crea un tipo options a partir de llamar al método create_DialogOptions() definido en SP.UI.
-
A partir de aquí se configuran los distintos parámetros de la ventana modal y se modela el comportamiento de gestión del valor de vuelta a la página desde la que se abrió la ventana modal. Para ello se crea el correspondiente delegado que establece la comunicación a realizar con la página origen en el caso en el que se cierre la ventana modal (función CloseCallBack).
-
A continuación simplemente mostramos la ventana modal que hemos configurado a través de SP.UI.ModalDialog.showModalDialog() que recibe el objeto options que contiene las configuracioens comentadas.
-
La función CloseCallback() es la que realiza las operaciones definidas en el caso en el que se cierre la ventana modal. En este caso, mostrar un mensaje al usuario.
-
En cuanto a la acción de llamar a OpenDialog(), la tenéis definida en el botón Mostrar Diálogo.
-
A continuación he añadido al proyecto una sencilla página HTML y la correspondiente feature en la sección feature.
-
Una vez añadida y configurada la feature realizamos el despliegue del proyecto a través de la opción deploy.
-
Abrimos la página de aplicación en el navegador y comprobamos que al pulsar el botón se muestra nuestra ventana modal.
-
De la misma forma, al cerrar la página comprobamos que tiene lugar la comunicación efectiva con la página que realizo la llamada originalmente.
En SharePoint 2010, depurar los artefactos que se pueden crear (Web Parts, manejadores de eventos, workflows, …) es realmente sencillo desde Visual Studio 2010 gracias a que tenemos la posibilidad de depurarlos sin más que pulsar la tecla F5. De esta forma, y de modo automático, Visual Studio realiza el atachado del proceso de IIS correspondiente (worker process), ejecuta el explorador web con el Sitio de trabajo y ya estamos listos. Ahora bien, nos podemos encontrar con situaciones en las que tengamos que utilizar la opción Attach to process de Visual Studio 2010 y engancharlos a los Worker Process de IIS. El caso es que en la Beta2 de Visual Studio 2010, por defecto no aparecen estos procesitos y para poder tenerlos disponibles se necesita:
-
Ejecutar Visual Studio 2010 como usuario administrador.
-
En la opción attach to process, seleccionar la opción Show processes in all sessions y listo.

Con jQuery podemos añadir multitud de efectos a nuestro sitio de SharePoint que no solamente sea un efecto llamativo, sino funcional también (como en este otro post).
Lo que pretendemos es añadir funcionalidad a un formulario por defecto de Sharepoint como los DispForm.aspx, para mostrar datos de una forma mas ergonómica, sin necesidad de mostrar una gran párrafo del cual solo necesitaremos el encabezado.
Mediante SharePoint Designer, en el menú insertar, SharePoint Controls, custom list form, seleccionando el origen de datos prueba (lista previamente creada), y todo en DispForm_copy.aspx. Así pues conseguí incrustar el script en una placeholder que la pagina no usaba para nada, los estilos también fueron incrustados justo antes de la etiqueta <WebPartPages:DataFormWebPart> , entonces solo nos queda modificar la tabla que ha sido creada al insertar el custom list form.
Suelo añadir un div dentro del TD que contiene la información añadida ya que da más libertad para las transformaciones.
Como estamos tratando con jQuery deberemos añadir el script que nos ofrece las múltiples funciones para realizar efectos y diferentes funcionalidades:
|
<asp:Content runat="server" ContentPlaceHolderid="PlaceHolderPageImage">
<script type='text/javascript' src='/js/jquery-1.3.2.min.js'></script>
<script type="text/javascript">
$(function () {
$('.expandInfo a').click(function () {
$(this.hash).slideToggle(2000);
return false;
});
})
</script>
</asp:Content>
|
Elegí ese content place holder porque no se utilizaba en este marco, como veis tengo una libreria de js solo para tener ordenados los scripts, seria también valido, llamar al recurso publico en google o colocarlo en _layouts del directorio 12 (14 para SP2010):
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js" type="text/javascript"></script>
Los estilos, justo antes de la etiqueta:<WebPartPages:DataFormWebPart>.
|
<style type="text/css" media="screen">
#expand2 { background-color: #fff; display: none;}
#expand2 div { padding: 16px; }
.expandInfo { background-color: #fff; margin: 0; padding: 10px; }
a { color: #0000C4; text-decoration: none;}
</style>
|
Y finalmente localizar la zona donde queremos queremos añadir texto adicional, con SharePoint Designer lo tenemos fácil, en la vista de diseño nos posicionamos en la tabla sobre el TD escogido.
|
<td width="400px" valign="top" class="ms-formbody">
<p class="expandInfo"><xsl:value-of select="@Title"/><a href="#expand2>+</a></p>
<div id="expand2">
Para que se produzca el efecto persiana en cada TD debemos utilizar clases diferentes enumeradas para mejor control, esta es Expand2.
</div>
</td>
|
Este seria el aspecto del formulario creado:
Nos muestra datos de la lista de Sharepoint que podemos acotar, o añadir explicaciones propias pulsando el “+” que vemos al final de cada TD. Demostración de la animación:
Fuente:http://jqueryfordesigners.com/demo/animation-jump.html
Saludos y Felices Fiestas a todos los lectores del blog.
Jesús del Rio.
Microsoft acaba de liberar las versiones de WSS 3.0 & MOSS que incluyen el SP2 de serie. Los enlaces de descarga para cada producto son los siguientes:
-
Para WSS 3.0:
- Para MOSS (Versión trial):
Una de las novedades de SharePoint 2010 es la posibilidad de crear artefactos de SharePoint 2010 en modo SandBox, es decir, que se ejecuten en un entorno aislado de manera que si hay algo erróneo en los mismos, no se afecte a la granja completa sino a un nivel inferior. Ese nivel inferior es el que determinan las Colecciones de Sitios ya que son los administradores de las mismas los encargados de subir y cargar las soluciones SandBox. De esta forma, si el artefacto desplegado presenta un problema que introduzca una penalización en el rendimiento, alguna mala práctica de codificación o la simple violación de una regla, únicamente afectará a la Colección de Sitios donde se haya activado.
Precisamente al ser los administradores de la Colección de Sitios los encargados de subir y activar esta solución introduce otra ventaja: no es necesario recurrir al administrador de la granja para que despliegue este tipo de soluciones. De esta manera, se puede dedicar a monitorizar que soluciones están dando problemas en una cierta Colección de Sitios, monitorización que por otro lado es realizada automáticamente por el sistema que se encarga de generar los correspondientes avisos y bloquear aquellas soluciones SandBox que estén dando problemas. Por otro lado, este tipo de soluciones vienen a resolver el problema que se encontraban los administradores de SharePoint a la hora de desplegar estos artefactos: como securizarlos. Una solución de tipo SandBox se ejecuta de forma segura per sé y evita estos quebraderos de cabeza a los administradores. En este primer post sobre soluciones de tipo SandBox veremos cuales son sus características principales.
¿Qué artefactos se pueden crear en modo SandBox?
Básicamente aquellos que no impliquen que se tiene que subir archivos a disco o ensamblados a la GAC. Por lo tanto, no podremos crear web parts de tipo visual. Estos artefactos son:
- Web Parts clásicas.
- Listas.
- Plantillas de lista.
- Acciones personalizadas.
- Workflows
- Manejadores de eventos.
- Tipos de contenidos.
- Columnas de Sitio.
¿Cuál es el límite que tengo en mis desarrollos a nivel de modelo de objetos?
Pues básicamente, dentro de una solución SandBox sólo se permite desarrollar desde el nivel de Colección de Sitios hacía abajo. Además, hay restricciones como que no es posible utilizar SPSecurity y otras clase de seguridad. Asimismo, no es posible crear colecciones de sitios con SPSite. Visual Studio 2010 se encarga de ocultar en el intellisense el que se pueda hacer uso de estas clases…ahora bien, como veremos, esta limitación se puede superar de forma sencilla :-(.
Probando las prestaciones de las soluciones SandBox
Para probar las prestaciones de las soluciones SandBox, voy a crear una WebPart clásica en la que incumpla alguna de las condiciones comentadas. En mi caso, voy a hacer uso de SPSecurity:
-
Para ello, en primer lugar he creado un proyecto vacío de SharePoint 2010.
-
En el asistente de creación del proyecto he indicado que el despliegue se va realizar en modo SandBox.
-
A continuación he añadido un nuevo elemento al proyecto de tipo Web Part (la clásica) al proyecto.
-
En el método CreateChildControls() de la Web Part, he intentado hacer uso de SPSecurity, pero el intellisense de Visual Studio 2010 no me lo mostraba por ningún lado como era de esperar, ya que no se permite su uso en soluciones de tipo SandBox.
-
Ahora bien, nada impide que añadamos SPSecurity porque conocemos esta clase y entonces el intellisense si que aparece…mi gozo en un pozo :-(. Una clase que está prohibida en las soluciones de tipo SandBox se puede usar sin problemas, ya que no se hace ningún tipo de chequeo en tiempo de codificación y de compilación de que el código que se está utilizando sea permitido o no. El problema viene dado porque nuestro proyecto tiene una referencia al ensamblado Microsoft.SharePoint.dll almacenado en la carpeta ISAPI, es decir, a todo el modelo de objetos de SharePoint.
-
Pero veamos que pasa si la usamos. Para ello, en el método CreateChildControls de la Web Part he añadido el siguiente código:
|
base.CreateChildControls();
Label lblData = new Label();
SPSecurity.RunWithElevatedPrivileges(delegate
{
lblData.Text = "This shouldn't work";
});
this.Controls.Add(lblData);
|
- Tras compilar mi Web Part, he hecho el despliegue de la misma a través de la opción Deploy de Visual Studio 2010. El despliegue se realiza sin problemas.
Usando la Web Part en un Sitio de SharePoint 2010
Para utilizar una Web Part creada en modo SandBox, tenemos que:
-
Navegar hasta la administración de la Colección de Sitios dónde se ha desplegado.
-
Dentro de la sección Galerías, hacemos clic en Soluciones. Esta biblioteca especial contiene todas las soluciones de tipo SandBox (por supuesto, son archivos .WSP) que se hayan desplegado en la Colección de Sitios.
-
Comprobamos que nuestra WebPart aparece y está activada (Visual Studio activa la Web Part en el proceso de despliegue…realmente activa la característica correspondiente.
-
Si ahora utilizamos nuestra Web Part en nuestro Sitio de SharePoint 2010, veremos que se muestra un error…estamos utilizando un objeto no permitido, es decir, en tiempo de ejecución si que se comprueba que el código del artefacto desplegado esté utilizando elementos permitidos.
¿Cómo evito estas situaciones?
Esta es la pregunta que muchos os estaréis haciendo, y la respuesta es que de dos formas:
-
La primera es marcar a fuego a tu equipo de desarrollo de SharePoint que cuando creen soluciones SandBox utilicen la librería Microsoft.SharePoint.dll contenida en [..]\14\UserCode\Assemblies\Microsoft.SharePoint.dll que contiene aquellos elementos del modelo de objetos de SharePoint 2010 que se pueden usar en soluciones SandBox. De esta forma, se evita que se usen objetos no permitidos ya que Visual Studio 2010 mostrará el correspondiente error. Luego, cuando el artefacto de SharePoint 2010 esté concluido cambiamos la referencia por la original y que contiene toda el modelo de objetos de SharePoint 2010. Cómo veis, el error que se muestra es que SPSecurity no existe en el contexto actual.
-
La segunda es crear un validador de soluciones SandBox que en el proceso de despliegue de la solución analice el código y no active la solución en el caso de detectar algo erróneo. SharePoint 2010 por defecto incluye un validador, pero no chequea el código. Si chequea por ejemplo que no se esté intentando desplegar un artefacto que requiera copiar archivos en disco o ensamblados en la GAC.
Y hasta aquí llega este primer post sobre soluciones SandBox. Espero que os haya parecido interesante.
Esta semana tuve la oportunidad junto al bueno de Gustavo Vélez de impartir en España, y gracias al departamento de DPE de Microsoft Ibérica, el training de Ignite sobre desarrollo en SharePoint 2010. Han sido tres jornadas intensas en las que hemos tenido la oportunidad de mostrar las principales novedades a nivel de desarrollo en SharePoint 2010, y dónde los asistentes han tenido la posibilidad de trastear bastante con el producto. Desde el punto de vista personal, este training me ha permitido fortalecer los conocimientos que voy adquiriendo de la plataforma y también atreverme a realizarlo en inglés puesto que teníamos audiencia de habla España (24 valientes de distintos partners de Microsoft en España) y también de habla inglesa, por lo que tanto Gustavo como yo nos tuvimos que repartir las sesiones a realizar en castellano e inglés…lógicamente, los asistentes de habla inglesa fueron los que más contentos se fueron del training porque tenían un instructor para sólo dos alumnos :P.
En cuanto al contenido del training, es exactamente el mismo que podéis encontrar en:
Agradecer a todos los asistentes el alto grado de participación e interacción en el training ya que de esta forma se pudo profundizar aún más en algunas de las novedades introducidas. Y nada, aquí os dejo algunas fotos que hicimos durante las sesiones.
Seguro que en el 2010 se realizarán más iniciativas de este tipo. La comunidad de SharePoint en España es muy fuerte y hay que apostar por ella.
Una de las capacidades que se mejora notablemente en SharePoint 2010 comparado con SharePoint 2007 es el soporte de almacenamiento remoto de BLOBs. En este sentido, dentro de TechNet podemos encontrar una sección completa dedicada al soporte de este tipo de almacenamiento: Manage Remote BLOB Storage.
En el caso de SharePoint 2007, cuando salió el producto del horno, no presentaba esta capacidad, sino que se añadió posteriormente para soportar la característica FILESTREAM de SQL Server 2008. En este enlace podéis encontrar información sobre como utilizar FILESTREAM con SharePoint 2007.

Desde el pasado 14 de diciembre tenemos disponible una actualización del training kit para desarrollo en SharePoint 2010. En este kit podréis encontrar una serie de laboratorios, presentaciones, vídeos y código de ejemplo para desarrollar en SharePoint 2010. Podéis bajaros el kit de este enlace.

Siguiendo con la serie de posts en torno a las novedades que podemos encontrarnos en la instalación de SharePoint 2010 (puedes acceder al último post en este enlace), en esta ocasión vamos a ver lo sencillo que resulta instalar las Microsoft Office Web Applications (OWA). En este caso he realizado la instalación sobre SharePoint Foundation 2010, que permite usar las OWA aunque no de forma completa a como podemos hacerlo en SharePoint Server 2010. Los pasos de instalación son los siguientes:
-
En primer lugar especificamos la clave de las OWA.
-
Aceptamos los correspondientes términos de licencia.
-
Elegimos el path de instalación de las OWA y pulsamos Install Now.
- A continuación se inicia el proceso de instalación de las OWA, que concluirá con la típica pantalla de ejecución del asistente de configuración de SharePoint.
- En la siguiente pantalla del asistente dejamos marcada la opción por defecto (no desconectar de la granja actual) y pulsamos Next.
- En la siguiente pantalla dejamos de nuevo marcada la opción por defecto y pulsamos Next.
- A continuación se inicia el clásico configurador de SharePoint.
-
Concluido el configurador, se abrirá la Administración Central de SharePoint para que a través del correspondiente asistente configuremos los nuevos servicios relativos a las OWA.
-
Una vez finalizado el asistente, ya tendremos las aplicaciones de servicio correspondientes a las OWA ejecutándose en la granja.
-
Finalmente, a nivel de colección de sitios tendremos las correspondientes features relativas a las OWA.
Y hasta aquí llega este tercer post sobre novedades en instalación en SharePoint 2010.
El equipo de ADO.NET Data Services acaba de liberar la actualización de esta tecnología para .NET Framework 3.5 SP1. Esta actualización permite que podamos utilizar las características de ADO.NET Data Services disponibles en .NET Framework 4.0 y Visual Studio 2010 en Visual Studio 2008 y .NET Framework 3.5 SP1. Los enlaces de descarga de la actualización son los siguientes:
-
Para Windows 7 y Windows Server 2008 R2, puedes utilizar
este enlace.
-
Para el resto de versiones de Windows, puedes utilizar
este enlace.
Respecto a lo que contiene esta actualización, comentaros que se trata de todas las capacidades que teníamos en ADO.NET Data Services 3.5 incluyendo la posibilidad de realizar consultas contra listas de SharePoint 2010.
Ya tenemos disponible la cumulative update de diciembre de 2009 para WSS 3.0 & MOSS:
Una de las preguntas que seguro que se van a hacer con frecuencia los desarrolladores de SharePoint es que métodos y tipos se han marcado como depreciados en SharePoint 2010…pues nada, para saberlo no hay más que darse una vuelta por este enlace de MSDN donde podremos encontrar un listado de estos métodos y tipos que no deberíamos utilizar en nuestro código para evitarnos problemas en migraciones y actualizaciones futuras (a SharePoint 2014 ;-)).
Pues eso, saliéndome un poco de la temática técnica que es habitual en el blog, aquí os dejo el enlace a la página que da oportunidad a ganar una XBox dorada (date prisa que sólo hay 6), además añade al paquete varios juegos y una suscripción XBox Live para lo que te dura la XBox. Ale, a por los retos.
Una de las novedades que incorpora SharePoint 2010 es la posibilidad de definir acciones de usuario a través de SharePoint Designer 2010 (SPD 2010) o del modelo de objetos. Básicamente se trata de añadir comandos personalizados en lugares como:
-
La Ribbon de SharePoint 2010.
-
Las barras de herramientas de formulario.
-
Las barras de herramientas de las vistas de lista.
-
En las páginas de configuración
Estos comandos personalizados o acciones de usuario se pueden definir a nivel de lista, sitio o colección de sitios y se caracterizan porque se crean de forma declarativa, es decir, no se añade código de ningún tipo por cuestiones de seguridad y estabilidad. En este post vamos a ver como crear una acción de usuario utilizando SPD 2010.
Creación de acciones de usuario con SPD 2010
Para crear una acción de usuario con SPD 2010:
- Abrimos un Sitio de SharePoint 2010 utilizando el backstage de SPD 2010.
-
Navegamos a la sección Listas y bibliotecas de SPD 2010 y seleccionamos una de las listas existentes. Al hacer clic sobre esa lista, se abrirá la correspondiente página de resumen (Nota: Esta página de resumen aparece por cada artefacto de SharePoint 2010 que puede ser tratado en SPD 2010).
-
A través de la Ribbon, seleccionamos la opción Acción rápida en la pestaña de Inicio. Esta opción es la que nos va a permitir crear las acciones de usuario. En este caso, vamos a crear una acción rápida para la opción Mostrar formulario.
- En la ventana que se abre podremos especificar parámetros como:
-
Una vez que la acción de usuario se ha creado, aparece en el listado de acciones de usuario disponibles en la página de resumen de la lista.
-
Si nos vamos a la lista concreta en la que hemos creado la acción personalizada y hacemos clic sobre un elemento existente, veremos que la acción definida por el usuario aparece en la Ribbon de visualización de la tarea (En este caso no se muestra ninguna imagen asociada porque no se ha indicado).
Y hasta aquí llega este post sobre acciones de usuario con SPD 2010.
Siguiendo con la serie de post relativos al soporte de LINQ en SharePoint 2010 a través de LINQ To SharePoint, en esta ocasión toca hablar de como podemos hacer Joins entre listas relacionales (a través de campos de Lookup) en SharePoint 2010. Pero antes de empezar, os dejo una referencia a los dos post previos de la serie sobre LINQ To SharePoint:
Soporte de Joins en SharePoint 2010
SharePoint 2010 permite relacionar listas, sin llegar a un status de asegurar integridad referencial, a través de los campos de Lookup y además habilita el que podamos definir consultas en las que se especifiquen Joins entre las listas relacionadas de forma similar a como lo podemos hacer al trabajar con tablas relacionadas en SQL Server. Para ello, Microsoft ha actualizado el esquema CAML de consultas de listas para añadir el soporte de Joins. Con respecto a este soporte, os resumo alguna de las características:
-
En principio no hay límite en el número de Joins que se pueda hacer, aunque aviso a navegantes: no todas las consultas que queramos van a hacer posibles ya que SharePoint analiza la eficiencia de las consultas antes de su ejecución. Si la consulta a realizar es ineficiente, se producirá la correspondiente excepción.
-
Los Joins los podemos hacer a nivel de CAML o a nivel de LINQ To SharePoint. La opción recomendada es esta última ya que sí el CAML que podíamos construir en SharePoint 2007 tenía su complejidad, al añadir Joins a SharePoint 2010 la definición se complica aún más.
-
Como consecuencia de poder realizar Joins, podremos devolver campos de las listas relacionadas. Los campos relativos a la lista padre se denominan campos proyectados.
Creando Joins en LINQ To SharePoint
Para probar el soporte de Joins en SharePoint 2010, he creado en primer lugar una lista padre denominada Empresa en la que he añadido un par de columnas adicionales a la lista para a continuación añadir un par de valores. A continuación:
-
He creado una lista Empleados en la que uno de los campos de la lista es de tipo Lookup. Este campo obtiene información de la lista Empresa y además lo he configurado para que se visualicen otros dos campos de información de esta lista.
-
A continuación he añadido una serie de datos a la lista Empleados.
Una vez creadas las listas, me he ido a Visual Studio 2010 dónde:
- He creado un proyecto para .NET Framework 3.5 de tipo Aplicación de Consola.
- He cambiado la plataforma por defecto de x86 a Any CPU (habría sido suficiente con x64) ya que es un requerimiento necesario para poder trabajar con el modelo de objetos de SharePoint 2010.
- He añadido dos referencias al proyecto a Microsoft.SharePoint y Microsoft.SharePoint.Linq.
-
A continuación, desde la línea de comandos y utilizando SPMetal he generado la clase proxy correspondiente para poder trabajar con las Listas y Bibliotecas del sitio de trabajo utilizando LINQ To SharePoint.
-
No todos los tipos de campos de SharePoint 2010 permiten definir Joins. Por ejemplo, los campos de tipo texto enriquecido no se pueden utilizar para definir Joins entre listas ni como campos proyectados.
|
string sSiteUrl = http://pegaso;
SPLINQProxySiteDataContext ctx =
new SPLINQProxySiteDataContext(sSiteUrl);
var ListaEmpleados =
from e in ctx.Empleados
select new{
Nombre=e.Nombre,
Empresa = e.Organizacion.Title,
SedeEmpresa = e.Organizacion.Sede,
PlantillaEmpresa=e.Organizacion.Plantilla
};
ctx.Log=Console.Out;
foreach (var e in ListaEmpleados)
{
Console.WriteLine(
"{0} - {1} - {2} - {3}",
e.Nombre, e.Empresa, e.SedeEmpresa, e.PlantillaEmpresa);
}
Console.ReadLine();
|
Por supuesto, otra consulta posible es hacer lo mismo y añadir algún tipo de filtro de manera que en el CAML generado aparece la condición Where correspondiente:
|
string sSiteUrl = http://pegaso;
SPLINQProxySiteDataContext ctx =
new SPLINQProxySiteDataContext(sSiteUrl);
var ListaEmpleados =
from e in ctx.Empleados
where e.Organizacion.Sede="Santander"
select new{
Nombre=e.Nombre,
Empresa = e.Organizacion.Title,
SedeEmpresa = e.Organizacion.Sede,
PlantillaEmpresa=e.Organizacion.Plantilla
};
ctx.Log=Console.Out;
foreach (var e in ListaEmpleados)
{
Console.WriteLine(
"{0} - {1} - {2} - {3}",
e.Nombre, e.Empresa, e.SedeEmpresa, e.PlantillaEmpresa);
}
Console.ReadLine();
|
Los resultados obtenidos en este caso son los siguientes:
Y hasta aquí llega este tercer post sobre LINQ To SharePoint. Espero que os haya resultado interesante.
Más artículos
Página siguiente >