Vamos a ver cómo podemos añadir un Verb personalizado a nuestro webpart en modo sandbox.

Un Verb en un webpart, es cada una de las acciones que tenemos disponible, cuando pulsamos sobre la flechita de las opciones de configuración del webpart. COmo siempre, una imagen vale más que mil palabras:

Como podemos apreciar en la imagen, aparece un Verb nuevo “Developed by ENCAMINA”. Si seleccionamos el verbo, nos abrirá una ventana nueva, y nos llevará a la web de ENCAMINA

En este fragmento de código tenemos el ejemplo para crear 2 verbs, uno que se ejecutará en el lado cliente, y otro en el servidor:

Para el lado servidor, definimos el manejador del evento:

Para acabar, OJO con lo que queréis hacer en el lado del servidor, ya que el evento se ejecutará antes que el CreateChildControls del WebPart, por lo que tened cuidado de que este último no sobreescriba el valor de algún control que actualicéis en el Verb.

Espero que os sirva!

Saludos.

Hola a todos, tan solo quería hacer eco del blog de Gustavo Velez, y re-anunciar que ya tenemos disponible el número 10 de CompartiMOSS, en el que he tenido la suerte de colaborar.

Podéis descargarlo desde aquí:

http://www.gavd.net/servers/compartimoss/compartimoss_main.aspx

Yo he colaborado con un par de artículos: el primero explica cómo podemos personalizar la página de error típica de SharePoint, y en el segundo, os presento un producto que hemos desarrollado en ENCAMINA de BI para hospitales y basado 100% en plataforma MS: SharePoint + SQL Server.

Os recomiendo que os leáis la revista de principio a fin, porque no tiene desperdicio.

Saludos!

Hoy os dejo un pequeño tip, de un problema que me he encontrado recientemente en SharePoint on-premise, y que me he decidido a probar en SharePoint Online, para ver si se sucede lo mismo, y, como era de esperar, sucede lo mismo.

Muy resumido, SharePoint utiliza internamente algunos parámetros de QueryString, para, por ejemplo, cargar el contexto en determinadas ocasiones. Por ejemplo, si ha cualquier página de SharePoint, le añades como QueryString el parámetro ID, y empiezas a darle valores aleatorios, seguramente más pronto que tarde, te encontrarás un pantallazo de error como el siguiente:

Nota: El pantallazo ya es del sitio de grupo de Office 365.

En este link de Stefan Gobner está algo más detallado, además de un listado con todos los parámetros “reservados”, y que por lo tanto no debemos utilizar en nuestros desarrollos:

http://blogs.technet.com/b/stefan_gossner/archive/2009/01/30/querystring-parameters-you-should-not-use-in-your-sharepoint-application.aspx

Copio los parámetros porque me fío más del servidor de Geeks, que de los de MS

• FeatureId
• ListTemplate
• List
• ID
• VersionNo
• ContentTypeId
• RootFolder
• View
• FolderCTID
• Mode
• Type
• PageVersion
• IsDlg
• Title
• _V3List_

Como buena práctica, convendría que antes de iniciar el desarrollo, el equipo fije algún tipo de “prefijo” para los parámetros a utilizar por query string.

Espero que os sirva.

Saludos!!

En este post vamos a ver un sencillo ejemplo de cómo podemos hacer uso del SDK de Lync 2010, desde un webpart de Silverlight, dentro de un site de Office 365.

Primero de todo, nesitaremos instalarnos:

• Microsoft Silverlight 4 tools for Visual Studio
• Microsoft Lync 2010 SDK

También nos ayudará conocer el centro de desarrollo de Lync 2010, con gran contenido de utilidad.

Manos a la obra!

Lo siguiente es crear un nuevo proyecto en Visual Studio, donde tras instalar el SDK, dispondremos de una nueva plantilla para proyectos Silverlight:

Le damos un nombre a nuestro proyecto, y en la siguiente pantalla, nos aseguramos de desmarcar la opción de crear un sitio web para hospedar al aplicación Silverlight. Luego os explico por qué.

La plantilla, ya nos creará un archivo Page.xaml, con un primer control de Lync, el PresenceIndicator.

Podéis ver un resumen visual de los controles que nos ofrece el sdk, en este post

Bien, ahora tenemos que cambiar la propiedad source, con una cuenta válida de nuestro dominio de Office 365. Esta propiedad admite varios formatos de valores:

• Un string empezando por “sip:” + una cuenta de usuario de office 365. Ejm: sip:john@controso.com
• Un string empezando por “tel:” + un número de teléfono en formato E.164
• Un string cualquiera. En dicho caso, Lync buscará contactos con ese string, y mostrará el primero que encuentre.
• Un objeto de tipo Contact:

Bien, de momento dejamos el proyecto Silverlight tal cual, y generamos el .XAP, que utilizaremos desde nuestro site de Office 365, subiendo el archivo .XAP a cualquier biblioteca de documentos que tengamos, y copiando la URL del archivo dentro de la biblioteca.

Ahora, basta con añadir un webpart estándar de Silverlight, y configurarlo a la URL del fichero XAP.

Si hemos seguido estos pasos, lo más probable es que nos llevemos una desagradable sorpresa, y nuestro control pinte un feo “unkwon contact”

Esto es debido a que, para que el control de Lync funcione, el sitio web que lo hospeda, de formar parte de los sitios de confianza de Internet Explorer.

Esta razón, era por lo que os decía que al crear el proyecto de Silverlight, no crease un sitio web para su despliegue, ya que nos hubiera pasado lo mismo, y para pruebas no es necesario un sitio web, ya que Visual Studio crea un archivo físico HTML temporal, que hospeda en el disco duro, y que funciona perfectamente para pruebas.

Una vez añadido nuestro sitio web, podemos recargar la página, y ya veremos nuestro control de presencia:

Nota: Tal y como he comprobado, al menos usando mi usuario en la configuración del control, también obtendremos un “Unkwon contact”, si no hemos inicializado nuestro cliente de Lync. Lo cual me desilusiona bastante, ya que lo suyo sería que apareciera el usuario en estado “No conectado”. Si descubro algo más al respecto, os lo haré saber.

Saludos!!

En un post de hace unos días os comentaba cómo funciona internamente SharePoint cuando usamos Linq to SharePoint y hacemos uso de la paginación de elementos en el propio Linq (con los métodos de Skip y Take).

En este post veremos qué pasa cuando hacemos uso de la API REST de listas.

Para los que no conozcáis que podemos hacer con REST a la hora de atacar listas, os dejo un par de referencias muy sencillitas, pero donde podemos ver muy claramente cómo empezar y sus beneficios:

• Overview of using REST in SharePoint 2010
• http://msdn.microsoft.com/en-us/library/cc907912.aspx en este link, además de mucha información sobre ado.net data services, hay unas tablas resumen muy buenas con la sintaxis REST (filtros, funciones, operadores…)

Si queremos usar paginación en REST, lo haríamos de la siguiente forma:

http://team.server.lab/_vti_bin/ListData.svc/Questions?$skip=20&$top=20

Pues bien, si volvemos a usar el SQL Profiler para trazar el resultado de la SQL que genera SharePoint, nos encontramos con la misma SQL que si usamos Linq to SP:

ahí tenemos el NUMROWS con ese número… tan largo.

Nada más, como veis, a la hora de usar REST, tampoco estamos optimizando la paginación, así que tenerlo en cuenta en vuestros desarrollos.

Saludos!!

Os paso un par de métodos de la clase SPUtility que me han parecido de mucha utilidad y que creo que no son muy conocidos. Al mismo tiempo, os invito a que conozcáis con más detalle todo lo que nos ofrece esta clase, que es mucho, y que seguro que nos puede ahorrar algún método.

Aquí tenéis la definición completa de la clase:

http://msdn.microsoft.com/en-us/library/ms462952.aspx

Y los métodos que os recomiendo utilizar son:

Este es el resultado del TransferToErrorPage.

Y este el de TransferToSuccessPage

El segundo parámetro, indica la URL a la que redirige al pinchar en el botón de OK. Los otros 2 parámetros, deberían ser un texto, y una URL. Sin embargo, no he conseguido que funcionen de ninguna manera ¿?

¿Y en Office 365?

No, por desgracia, estos 2 métodos no están disponibles en modo sandbox, así que no podemos usarlos en Office 365.

Saludos!!

En el post anterior os hablaba de Linq to SharePoint y la posibilidad de usarlo en Office 365. Ahora os quiero contar algunas observaciones del funcionamiento. Lógicamente, las pruebas que he hecho sólo son posibles en modo on-premise, pero estoy casi seguro de que se comporta igual en la versión 365.

Antes de nada, tiene que quedar claro que Linq to SharePoint, internamente, funciona con consultas CAML, igual que hace por ejemplo el SPQuery. Podemos ver qué CAML autogenera Linq to SP, asignando la propiedad Log del DataContext. El siguiente snippet es un ejemplo de uso de Linq2SP haciendo debug de la CAML generada:

Además, el ejemplo anterior realiza una consulta “paginada”, es decir, nos saltamos los primeros 10 elementos, y devolvemos los siguientes 10 (vamos, dame la página 2, cuando paginamos de 10 en 10).

Si vemos la CAML generada, tenemos:

Fijaros en el último atributo:

2 mil, cien millones, 47… uff, un número muy largo, vamos

Pues sí, la cosa está clara. Cuando usamos Linq 2 SP, aunque paginemos desde LINQ, la CAML generada, y por tanto, la SQL final que llega al servidor de BD, devuelve todos los elementos de la lista, y la paginación, se hace en memoria, lo cual, desde luego, no es lo ideal para temas de rendimiento, así que tenerlo en cuenta.

Por cierto, también estuve haciendo la traza desde el SQL Profiler, y os dejo la SQL tan intuitiva que genera SharePoint: