[Infopath] Control de selección de usuario

Cuando diseñamos un formulario para ser utilizado en Infopath Forms Services debemos tener en cuenta que no todos los controles son compatibles con el explorador. Esto se debe a que el cliente de Infopath es mucho más rico que el motor de Infopath Form Service, debemos verificar en el diseño si nuestro control es compatible en modo explorador.

Nos puede surgir el caso en el que el cliente nos solicite que el formulario pueda seleccionar un usuario del dominio, ¿Es este control compatible?, pues sí (a medias), pero debemos agregarlo a los controles personalizados ya que no aparece en la lista de controles estándar.

Desde la ventana de “Tareas de diseño” > seleccionamos agregar u ocultar controles personalizados > agregar… > control activex > contact selector

Para poder utilizarlo tendremos que tenerlo registrado, aunque también podemos hacer que el propio fichero xsn incluya el fichero .cab con la instalación del Activex.

Para que sea compatible con Infopath Forms Service debemos marcar “No incluir un fichero cab”.

En la pantalla siguiente de enlace de propiedades seleccionamos “value”. A continuación indicamos a Infopath como se guardarán los datos, seleccionamos “Campo o grupo (cualquier tipo de datos)”.

Al finalizar dispondremos del control para ser arrastrado al formulario. Solo quedaría asociarlo a un grupo de datos, pero este debe tener una estructura determinada.

En la sección de orígenes de datos “agregamos un campo o grupo” > seleccionamos > grupo > indicamos un nombre de grupo. Repetimos el mismo proceso e indicamos el nombre que representa el registro que se repetirá por cada uno de los controles, no os olbideis de marcar “repetir”. Por último agregamos al anterior grupo los campos de tipo texto: DisplayName, AccountId y AccountType.

Solo quedaría enlazar el control al grupo extensible seleccionando el control y con el botón derecho "cambiar enlace".

Al probar nuestro formulario sobre Sharepoint veremos algo similar a la siguiente imagen:

La entrada original la podéis encontrar en: Using the Contact Selector Control

[Infopath] Mostrar un formulario desde un WebPart

Siguiendo con el post anterior “[Infopath] Orígenes de datos”, veremos como visualizar un formulario de Infopath desde un WebPart. Recordar que para poder renderizar un formulario necesitaremos de Infopath Services, además tendremos que haber habilitado la compatibilidad del formulario para que se pueda abrir en el explorador, desde la opciones del formulario > Compatibilidad > compatibilidad de explorador > marcaremos “Diseñe una plantilla de formulario que se pueda abrir en un explorador o infopath”.

Utilizaremos el WebPart “XmlFormView” que está alojado en la librería Microsoft.Office.InfoPath.Server.dll. Antes de poder agregarlo debemos asegurarnos que lo tenemos registrado correctamente como safecontrol, agregaremos en el fichero web.config la entrada:

<SafeControl Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TypeName="*" Safe="True" />

A continuación iremos a la galería de elementos web en la configuración de nuestro sitio > seleccionaremos la opción “Nuevo” > marcaremos el webpart “Microsoft.Office.InfoPath.Server.Controls.XmlFormView” > Llenar galería. Esto hará que el webpart esté disponible para ser agregado desde cualquiera de las páginas de nuestra colección.

En la página que deseemos agregar el WP la editaremos y agregaremos el WP con título “XmlFormView”. La primera vez puede que nos muestre un error de infopath diciendo que no tenemos la plantilla adecuada, esto se debe a que todavía no lo hemos configurado y está intentando renderizar el formulario.

Editaremos entonces las propiedades del webpart añadido y en la sección “Enlace de datos” indicaremos el fichero xsn y la librería donde se guardarán los datos xml generados por el formulario.

En la propiedad XsnLocation indicaremos la ruta del fichero xsn, en mi caso he publicado desde Infopath el formulario de notas de gasto en una biblioteca de documentos de forma que la ruta queda: http://w2k3r2:17092/FormServerTemplates/EjemploNotasDeGastos.xsn

Si os aparece siempre el mensaje “Formulario cerrado” verificar el fichero de log de Sharepoint, que tenéis la url correctamente, que habéis indicado una ruta para SaveLocation y la propiedad “EditingStatus”. Aseguraros además que habéis publicado correctamente el formulario desde la administración central y lo habéis activado para la colección actual.

[Infopath] Orígenes de datos

Con infopath podremos manejar datos procedentes de distintos orígenes: Xml, Una base de datos, un servicio web y una lista de sharepoint.

Para manejar los orígenes de datos iremos al menú Tareas de diseño > Orígenes de datos, siempre tendremos al menos el origen de datos Principal como comentábamos en el anterior post “Formularios con Infopath”. Recordar que el origen de datos principal contiene la estructura del xml que generará Infopath al guardar el formulario.

Para agregar una nueva conexión seleccionaremos “Agregar conexiones de datos…”. Al seleccionar esta opción se abrirá una ventana con las conexiones de los distintos orígenes configuradas. Para agregar un origen de datoa tendremos que configurar primero la conexión y el tipo de acción lectura/escritura.

Los datos sensibles de las conexiones como pueda ser el usuario y contraseña se pueden guardar o bien incrustados en el infopath o en una librería de conexiones. Si incrustamos los datos de conexiones se guardarán dentro del fichero y solo podremos modificarlos editando el fichero xsn dede Infopath. Lo recomendable es que usemos fichero de conexiones, que consisten en ficheros con los datos de conexión y se alojan en sahrepoint, en caso de cambiar algún dato de conexión (por ejemplo al cambiar de entorno), solo tenemos que tocar el fichero de conexión y subirlo de nuevo. 

Leer datos

Agregaremos entonces una nueva conexión e indicaremos que deseamos “recibir datos”, a continuación indicamos desde donde queremos leerlos.

Leer de una base de datos

Mediante esta opción podremos ejecutar una consulta SQL contra una base de datos. Indicamos entonces que queremos leer de una base de datos y agregamos una nueva conexión. En mi ejemplo he creado una tabla con los tipos de gastos en mi SqlServer. La primer vez tendremos que crear un fichero de conexión de datos que se almacenará en nuestro pc, seleccionando la opción “Nuevo origen de datos” indicamos el tipo de conexión, en mi caso “Microsoft Sql Server“ y a continuación los datos de conexión (servidor, usuario, contraseña, etc). En caso de disponer del fichero solo tendremos que seleccionarlo.

Una vez hemos conectado con nuestra bbdd, elegiremos las tablas y campos a consultar o bien editamos nuestra consulta sql.

Por último, podremos indicar si queremos que almacene los datos en el propio fichero xsn y si queremos que ejecute la consulta al abrirse el formulario.

 

Ahora que tenemos configurado nuestro origen de datos, haremos que el control de tipo de gastos muestre los datos de este origen. En las propiedades del control seleccionamos “Buscar valores desde un origen de datos externo” > indicamos el origen previamente configurado. En el campo Entradas seleccionamos la tabla o la entrada de registro que queremos mostrar, en “valor” el campo que contiene valor del elemento seleccionado  y en “nombre para mostrar” el campo con la descripción que visualizará el usuario.

Para verificar que hemos configurado correctamente todo podemos realizar una vista preliminar y comprobar que se cargan todos los datos.

 

Leer datos de un servicio web

Seleccionamos como antes “agregar conexión de datos” > recibir > servicio web, indicamos la url de nuestro servicio web, para el ejemplo voy utilizar los servicios de Sharepoint para leer el contenido de una lista con los tipos de gastos, de manera que la url sería “http://w2k3r2:17092/_vti_bin/lists.asmx?WSDL”. Al darle a “Siguiente” el asistente de conexión mostrará todos los métodos disponibles, para el ejemplo he seleccionado “GetListItems” que corresponde con el método que devuelve todos los elementos de una lista de Sharepoint. Como existe un problema de interpretación de tipos entre Infopath y los servicios de Sharepoint, he necesitado de un servicio web intermedio que tenga una definición de tipos de parámetros que entienda Sharepoint (ver ejemplo : http://wssdev.blogspot.com/2007/06/infopath-use-sharepoint-web-services.html).

Al aplicar el servicio de proxy los tipos los he convertido a “string”, con lo que puedo establecer los parámetros obligatorios desde Infopath con la opción “establecer valor”. Una vez agregado el origen de datos volveremos a configurar nuestro control para que lo utilice. Fijaros que en este caso la estructura XML del origen de datos generada por el servicio es más compleja que la anterior.

Podéis descargaros el código del servicio web intermedio en http://blogs.renacimiento.com/mcortes/Documentos/WebService1.zip

 

 

Insertar Datos

Solo nos queda ver como guardar los datos introducido en el formulario. A este proceso Infopath lo llama “Envío de datos” y disponemos de los siguientes tipos de orígenes de datos: a un servicio web, a una biblioteca de sharepoint, por correo electrónico y a una página ASP.NET. En este caso no disponemos de la opción de una bbdd por lo que si queremos guardarlos en una tabla tendremos que utilizar un servicio web o una página ASP.Net. El problema que podemos encontrarnos si lo hacemos de este modo es que el envío puede que sea de un nuevo elemento o de una actualización, por lo que tendremos que ser nosotros los que detectemos esto.

Si lo queremos guardar en una biblioteca de sharepoint tenemos dos opciones, o bien definimos nuestro formulario como plantilla de una biblioteca o hacemos que el envío se haga hacia una biblioteca independientemente de donde se aloje nuestro formulario.

Para hacer que nuestro formulario aparezca al darle a´l menú “Nuevo elemento” de una biblioteca seleccionaremos la opción de archivo > publicar > en un servidor de sharepoint > indicamos la url.

Para enviar los datos a una biblioteca de documentos, seleccionamos Administrar conexiones de datos > agregar > enviar > a una biblioteca de documentos. Una vez creado el origen de envío indicaremos al formulario que debe usarlo para enviar los datos desde la opción Herramientas > opciones de envío > permitir a los usuarios enviar este formulario > biblioteca de documentos de sharepoint > Seleccionamos nuestra conexión de envío. Esto hará que al visualizar nuestro formulario aparezca una opción con el título “Enviar” y al seleccionarlo enviará el xml generado por infopath a la biblioteca indicada.

 

Ficheros de conexiones de datos

Hasta ahora las configuraciones de las conexiones a nuestros orígenes de datos se han guardado de forma embebida en el fichero xsn. Si ahora tuviéramos que utilizar nuestro formulario en otro entorno tendríamos que volver a editarlo y modificar los datos de conexión. Una forma de evitar esto es mediante el uso de ficheros de conexión, básicamente son ficheros xml con los datos de conexión que tendremos que subir a Sharepoint.

Podemos alojar los ficheros en dos sitios en una biblioteca de conexiones de una colección de sitios específica o en una biblioteca de conexiones de la administración central. Os recomiendo guardarlos en la administración central, aunque dependiendo del tamaño de vuestra granja puede ser recomendable la otra opción.

Para crear un fichero de conexión abriremos la lista de conexiones en “Administrar conexiones de datos” > Convertir > indicamos la url de la biblioteca de conexiones > seleccionamos el tipo de biblioteca de conexión.

Una vez guardado el fichero podéis descargarlo de la biblioteca y editarlo como un fichero xml.

Mi fichero de conexión a la bbdd es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<?MicrosoftWindowsSharePointServices ContentTypeID="0x010100B4CBD48E029A4ad8B62CB0E41868F2B0"?>
<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">
    <udc:Name>TiposDeGastos</udc:Name>
    <udc:Description>Format: UDC V2; Connection Type: Database; Purpose: ReadOnly; Generated by Microsoft Office InfoPath 2007 on 2009-03-30 at 01:29:53 by PIGNOISE\Administrador.</udc:Description>
    <udc:Type MajorVersion="2" MinorVersion="0" Type="Database">
        <udc:SubType MajorVersion="0" MinorVersion="0" Type=""/>
    </udc:Type>
    <udc:ConnectionInfo Purpose="ReadOnly" AltDataSource="">
        <udc:WsdlUrl/>
        <udc:SelectCommand>
            <udc:ListId/>
            <udc:WebUrl/>
            <udc:ConnectionString>Provider=SQLOLEDB.1;Password=misgastos;Persist Security Info=True;User ID=misgastos;Initial Catalog=Pruebas;Data Source=w2k3r2;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=PIGNOISE;Use Encryption for Data=False;Tag with column collation when possible=False</udc:ConnectionString>
            <udc:ServiceUrl UseFormsServiceProxy="false"/>
            <udc:SoapAction/>
            <udc:Query>select "IdTipo","Descripcion","Activo" from "dbo"."TiposDeGastos" as "TiposDeGastos"</udc:Query>
        </udc:SelectCommand>
        <udc:UpdateCommand>
            <udc:ServiceUrl UseFormsServiceProxy="false"/>
            <udc:SoapAction/>
            <udc:Submit/>
            <udc:FileName>Specify a filename or formula</udc:FileName>
            <udc:FolderName AllowOverwrite=""/>
        </udc:UpdateCommand>
        <!--udc:Authentication><udc:SSO AppId='' CredentialType='' /></udc:Authentication-->
    </udc:ConnectionInfo>
</udc:DataSource>

 

La forma de subir los ficheros está muy bien explicada en el post de Juan Carlos González enMOSS: Publicación de formularios Infopath…el otro camino!.

 

Podéis descargaros la nueva plantilla en http://blogs.renacimiento.com/mcortes/Documentos/EjemploNotasDeGasto2.xsn

Podéis descargaros el código del servicio web intermedio en http://blogs.renacimiento.com/mcortes/Documentos/WebService1.zip

 

Hasta aquí los orígenes de datos, hay muchas más opciones pero lo que no hay es tiempo, así que os dejo trastear.

Empezando con Infopath

Infopath es la solución que nos proporciona Microsoft para crear formularios de una forma rápida y ‘sencilla’. Tenemos dos formas de trabajar en modo cliente con los formularios: desde el cliente office de Infopath y desde un entorno web.

La idea de infopath es proporcionar una herramiena para diseñar formularios sin necesidad de realizar un desarrollo a medida o desplegar una gran cantidad de componentes. Infopath además permite manejar datos de entrada procedentes de varios orígenes de datos distintos: de una bbdd, un servicio web, un xml y una lista de sharepoint. Los datos que introducimos en el formulario de infopath se guardan en formato xml o son enviados a un destino configurado en tiempo de diseño.

Sharepoint tiene la capacidad de integrar los formularios infopath de forma ‘nativa’ de dos formas: mediante librerías de formularios y mediante Infopath Form services.

Las librerías de formularios consisten en librerías de documentos con una plantilla de infopath asociada, de forma que la edición de los elementos se maneja mediante el formulario Infopath y los datos manejados se almacenan en formato xml en la librería.

Infopath Form services consiste en un componente instalado en el servidor encargado de renderizar en Html los formularios diseñados en Infopath. Esto evita la necesidad de tener instalado el cliente Infopath para trabajar con los formularios. Para manejar los formularios con Infopath Form services tendremos que subirlos a Sharepoint desde la administración central e indicar en que sitios podremos manejarlos. En el post “MOSS: Publicación de formularios Infopath…el otro camino!” podéis encontrar como publicar un formulario.

Una vez configurados podremos visualizarlos en nuestros sitios con el webpart XmlFormView, si no lo tenéis habilitado podéis consultarlo en “Embedding InfoPath Form in SharePoint Page”.

[Sharepoint] Introducción al desarrollo

Los últimos meses nos hemos centrado en preparar una serie de post para ayudar a los desarrolladores iniciados en Sahrepoint para darles un empujón y una guía básica.

Os resumo los post más relevantes:

 

¿Por donde empezar?

Quick reference Sharepoint

Referencia con enlaces imprescindibles para empezar a desarrollar en un entorno Sharepoint.

Best Practice en el desarrollo con Sharepoint

Referencias a post con best practices para el desarrollo con WSS3 y MOSS2007.

 

Herramientas

Herramientas para el desarrollo en Sharepoint

Lista con referencias a varias de las herramientas más utilizadas y recomendables para trabajar con Sharepoint.

Introducción a las Visual extension for Sharepoint

Introducción sobre como hacer un proyecto con VSeWSS.

Habilitar intellisense para Xml de definición de Sharepoint

 

Personalización y WebParts

Modificar la apariencia de nuestro sitio

Edición rápida desde Sharepoint Designer

Cómo realizar cambios en las páginas de sharepoint sin desarrollo.

WebPart de contenido con formato

Cómo definir nuestro propio WebPart de contenido con un formato diferente

Page Templates con ayuda del Sharepoint Designer

Más allá del Hola Mundo

Ejemplo de WebPart sin utilizar el Render.write.

Ajax sobre Sharepoint

Cómo montar ajax sobre una aplicación sharepoint.

Implementación de Contentypes

Cómo implementar contentypes en una solución

Capturando eventos en Sharepoint

Opciones del QuickLaunch de Wss3 mediante SPNavitaionProvider

Cómo modificar el Quicklaunch.

Definir Lookup Site Columns desde una Feature

 

Seguridad

Cambiar las credenciales de usuario en Sharepoint

Asignación CAS de Sharepoint por contexto de usuario

 

Administración

Operaciones con Stsadm

Listado con las opciones de stsadm.

Ejecutar de manera inmediata de un job con stsadm

Añadir y desplegar una solución en Sharepoint

Security Provider con ADAM en MOSS y WSS3

MOSS and Hyper-V

Post de Enrique blanco sobre las ventajas de montar MOSS sobre Hyper-V

PowerShell & SharePoint I

Post de Álvaro Arias acerca de como utiliza powershell con Sharepoint.

 

Hasta aquí la temática sobre la “Introducción al desarrollo con Sharepoint”, ahora nos centraremos en temas un poco más avanzados como: Search Server, Infopath, Excel services, etc..

Más allá del Hola Mundo

Vamos a ver si conseguimos ampliar la documentación acerca de como crear un WebPart que no sea el típico “Hola Mundo”. En el mundo real nos vamos encontrar con multitud de situaciones en las que los ejemplos se quedan cortos.

Continuando con la temática de introducción veremos como crear un WebPart de forma “sencilla” sin utilizar el Response.write.

Crearemos un WebPart que nos permita buscar sobre una lista basada en el contentype comentado en el anterior post “Implementación de Contentypes”.

Podéis descargaros el ejemplo completo en: http://blogs.renacimiento.com/mcortes/Documentos/WPVistaEmpleado.zip

 

Empezaremos creando un proyecto del tipo WebPart con las extensiones “VseWSS”.

Para mostrar la parte de interfaz en lugar de utilizar el Response.write cargaremos en tiempo de ejecución un control de usuario mediante el uso de “LoadControl”. Con el control de usuario podremos diseñar nuestra interfaz de forma sencilla con una vista típica de un fichero ascx.

Cargaremos el control desde la función “CreateChildControls” del Webpaprt. En la función LoadControl tendremos que indicarle la ruta donde del fichero ascx, utilizaremos el directorio “CONTROLTEMPLATES” de sharepoint para alojar nuestro fichero. En este directorio podremos almacenar controles de usuario ascx sin tener que registrarlos como “safemode” en el webconfig. Además podremos acceder desde la ruta virtual "_controltemplates”.

 

public class WebPart1 : System.Web.UI.WebControls.WebParts.WebPart
    {
        public WebPart1()
        {
        }

        protected override void CreateChildControls()
        {
            base.CreateChildControls();

            string urlUserControl = @"/_controltemplates/UCVistaEmpleado.ascx";
            Control userControl = this.Page.LoadControl(urlUserControl);
            userControl.ID = "UCVistaEmpleado";

            this.Controls.Add(userControl);
        }
    }

 

Añadiremos entonces a nuestro proyecto un elemento del tipo “Template” y sobre el crearemos la subcarpeta “CONTROLTEMPLATES” y agregaremos un fichero con la extensión ascx y escribiremos la interfaz que deseemos. Para darle funcionalidad a este control tendremos que indicarle al fichero ascx la clase codebehind que la manejará.

Añadiremos una clase que herede de “UserControl” e indicaremos esta clase en el atributo “Inherits” de la directiva “Page”.

Para poder utilizar controles o elementos de sharepoint también registraremos la dll Microsoft.SharePoint y aquellas que necesitemos.

 

<%@ Control Language="C#" Inherits="WPVistaEmpleado.UCVistaEmpleado, WPVistaEmpleado, Version=1.0.0.0,Culture=neutral,PublicKeyToken=37ea3d63d16eb294" compilationMode="Auto" %>
<%@ Register Tagprefix="wssawc" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

 

Para conocer el publicKeytoken sin tener que desplegar el webpart utilizaremos la opción “Package” y consultaremos el publicKeytoken generado en el fichero webpart en el directorio bin.

Ahora agregaremos un SPGridView para mostrar los empleados disponibles y una serie de controles de filtro.

Para manejar los controles desde la clase manejadora definiremos las variables necesarias y las inicializaremos en el evento OnInit.

 

protected SPGridView ListaDeEmpleados;
protected TextBox txtNumeroEmpleado;
protected Button btnBuscar;

protected override void OnInit(EventArgs e)
{
            base.OnInit(e);

            txtNumeroEmpleado = (TextBox)this.TemplateControl.FindControl("txtNumeroEmpleado");
            btnBuscar = (Button)this.TemplateControl.FindControl("btnBuscar");
            btnBuscar.Click += new EventHandler(btnBuscar_Click);
            ListaDeEmpleados = (SPGridView)this.TemplateControl.FindControl("ListaDeEmpleados");
}

 

Fijaros que para capturar los eventos los hemos registrado por código ya que el LoadControl no lo hará por nosotros. Si queremos ahorrarnos este proceso podremos plantearnos introducir nuestro control en un UpdatePanel de Ajax de manera que sea éste el que enganche los eventos definidos en el ascx con nuestra clase.

 

Una vez hemos terminado nuestro control, solo tenemos que desplegarlo y agregarlo en nuestra página de contenidos.

 

Podéis descargaros el ejemplo completo en: http://blogs.renacimiento.com/mcortes/Documentos/WPVistaEmpleado.zip

Implementación de Contentypes

Los contentypes serán uno de nuestros elementos en nuestros desarrollos sobre Sharepoint.

Para ver una introducción acerca de los contentypes y cómo manejarlos desde la interfaz gráfica podéis leer el post “Tipo de Contenido en SharePoint” de Jorge Diéguez.

En este post nos centraremos en la definición de contentypes mediante features creadas con “Herramientas para el desarrollo en Sharepoint”.

Empezaremos por definir nuestro contentype desde la interfaz gráfica. Con esto conseguiremos que Sharepoint cree la definición del contentype por nosotros. Para extraer esa definición a xml utilizaremos alguna de las herramientas disponibles como: Sharepoint Manager, FieldsExplorer o Feature Generator.

Para el ejemplo crearemos en Sharepoint un contenttype para almacenar los datos de los empleados. Definimos entonces el contentype Empleados con las columnas: Nombre, apellidos, número empleado.

Una vez creado el tipo de contenido, abriremos el Visual Studio y crearemos una solución con las extensiones de VSeWSS. Crearemos un proyecto del tipo “Empty” y añadiremos un elemento del tipo “ContentType”. Al añadir el elemento Visual studio nos preguntará sobre que tipo primario queremos que herede nuestro contentype. En este caso elegiremos “Item” o “elemento”, aunque podremos elegir cualquiera de los primarios que nos aparezca en la lista.

Sobre la vista VSeWSS veremos una nueva Feature, en mi caso con el nombre “EmpleadosContentType”.

Abriremos a continuación el fichero Xml que nos a generado las extensiones. En mi caso “EmpleadosContentype.xml”. Veremos que tenemos una definición de un contentype que hereda del tipo primario “Item”.

Este xml será el que defina nuestro contentype. En la sección fieldrefs añadiremos todas las referencias a los tipos de columnas o “Site columns” definidas previamente. En caso de tener que utilizar nuevos tipos de columnas las podremos definir mediante el tag “Field” bien en este fichero o en otro de esta u otra feature. Cada site column tiene un GUID único, por lo que para referenciarla utilizaremos este valor especificado en el atributo “ID”. En caso de utilizar columnas estándar definidas por Sharepoint, tendremos que buscar sus GUID’s y no será necesario tener que definirlas de nuevo.

Para obtener toda esta información utilizaremos Sharepoint Manager 2007. Navegaremos a nuestra colección y desplegaremos el elemento “Content types” alojado en la raíz de la colección. A continuación seleccionaremos la pestaña “Schema Xml”.

Esto nos mostrará la definición de nuestro content type en xml. Copiaremos el Xml generado y lo pegaremos en nuestro fichero XML dentro del tag “Elements”. Sharepoint Designer nos mostrará el xml de la instancia, por lo que tendremos que realizar algunos ajustes sobre el xml.

Para asegurarnos que las modificaciones tienen la estructura correcta, activaremos la validación del intellisense.

A continuación moveremos todos los elementos Field fuera del tag contentype y quitaremos todos los atributos subrayados como no reconocidos por el intellisense.

A continuación crearemos un elemento “FieldRef” por cada campo del contentype con los GUID de los campos que desplazamos previamente.

En mi ejemplo queda un xml como el siguiente:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="ad412d2a-bf6b-4ebe-bcd8-fb32fd01347f" xmlns="http://schemas.microsoft.com/sharepoint/">

<ContentType ID="0x0100D4030561D9561C4BB0330408060E5817" Name="Empleado" Group="Tipos de contenido personalizados">

<FieldRefs>

<FieldRef ID="{4a722dd4-d406-4356-93f9-2550b8f50dd0}" Name="FirstName" />

<FieldRef ID="{06b22ccb-9e3d-41d4-884f-4faf85d8c934}" Name="Apellidos" />

<FieldRef ID="{b0f31712-0348-4248-9fde-1cb33839da68}" Name="NumeroEmpleado" />

</FieldRefs>

</ContentType>

<Field ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="ContentType" Group="_Hidden" RowOrdinal="0" Type="Text" DisplayName="Tipo de contenido" ReadOnly="TRUE" Sealed="TRUE" ColName="tp_ContentType" PITarget="MicrosoftWindowsSharePointServices" PIAttribute="ContentTypeID" />

<Field ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Title" Group="_Hidden" Type="Text" DisplayName="Título" Required="TRUE" FromBaseType="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />

<Field ID="{4a722dd4-d406-4356-93f9-2550b8f50dd0}" Name="FirstName" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="FirstName" Group="Columnas de calendario y contacto principal" DisplayName="Nombre" Type="Text" />

<Field Type="Text" DisplayName="Apellidos" Required="FALSE" MaxLength="255" Group="Columnas personalizadas" ID="{06b22ccb-9e3d-41d4-884f-4faf85d8c934}" SourceID="{d0b52269-2cb7-4c94-83c9-d40cf4207783}" StaticName="Apellidos" Name="Apellidos" />

<Field Type="Text" DisplayName="Numero Empleado" Required="FALSE" MaxLength="255" Group="Columnas personalizadas" ID="{b0f31712-0348-4248-9fde-1cb33839da68}" SourceID="{d0b52269-2cb7-4c94-83c9-d40cf4207783}" StaticName="Numero_x0020_Empleado" Name="Numero_x0020_Empleado" />

</Elements>

 

Ahora solo nos queda desplegar nuestra solución y activar la feature. Pero antes de hacer esto, como lo que estamos haciendo con nuestra feature es volver a definir un contentype que ya tenemos instanciado con el mismo GUID, nos aseguraremos de eliminarlo y las site columns definidas. Si no queremos hacer esto, podremos cambiar el nombre y los GUID del contenttype y de las sitecolumns

Para generear el XMl también podría haber utilizado “Fields Explorer” que nos permite exportar rápidamente los contentypes y site columns ya definidos.

Documentación Microsoft Dynamics NAV 2009

Microsoft ha publicado varias guías para el desarrollo, instalación y administración de Nav2009. podéis descargarlo en “Microsoft Dynamics NAV 2009 Developer and IT Pro Help”.

Os recomiendo algunos post como: “Microsoft Dynamics NAV Team Blog”, “Clausl's Dynamics NAV Blog”, “Freddys Blog”, “Waldo’s blog”, “Kine’s blog”

Introducción a las Visual extension for Sharepoint

Las VSeWSS (Visual extension for Sharepoint) consisten en unas extensiones para Visual Studio para el desarrollo de soluciones y elementos de Sharepoint. Las VSeWSS nos ayudarán a construir los esqueletos de nuestras soluciones, features, webparts y sobre todo nos ahorrará trabajo a la hora de crear el fastidioso manifest de las soluciones.

Aunque existen otras soluciones similares como WspBuilder, VseWSS será una solución muy válida para nuestros proyectos.

Para utiliza VSeWSS crearemos un proyecto del tipo “Sharepoint”. Al seleccionar esta categoría veremos que podremos crear varios tipos de proyecto como: Definiciones de listas y sitios, webparts o proyectos vacíos para agregar lo que querramos.

Todos los proyectos que realicemos con VseWSS estarán compuesto por los ficheros propios que agreguemos y los que definan una solución de Sharepoint. Dentro de la solución se dividirá en varias features. Una solución de Sharepoint consiste en un fichero con extensión WSP que contiene todos los ficheros que creemos, sus definiciones y donde se alojarán al desplegarse la solución. Al agregar una solución a la granja estaremos almacenando el fichero en la bbdd de configuración. A continuación podremos desplegarla en los frontales que deseemos. Al desplegarla, Sharepoint copiará por nosotros los ficheros en todos los frontales y copiará las definiciones que correspondan. Si disponemos de una Web Application extendida solo tendremos que desplegarla en una de ellas ya que Sharepoint se encargará de replicarla.

Para este ejemplo crearemos un nuevo WebPart. Al seleccionarlo nos creará los ficheros para definir el webpart y los necesarios para crear la solución de sharepoint. Los ficheros de la definición de la solución y features están alojados en la carpeta “pkg” que no está agregada al proyecto. Para verla seleccionaremos la vista “Mostrar todos los ficheros”. Al hacerlo veremos la estructura del paquete una vez lo hayamos generado o previsualizado. Estos ficheros además los mantendrá el propio Vsewss automáticmanete, por lo que no tendremos que tocar nada manualmente a no ser que querramos hacer cosas avanzadas.

Solution.xml

Es un fichero propio de VSEWSS y contiene la definición de la solución describiendo que features se van a utilizar y que elementos la componen. Para construir el fichero de solución utiliza el guid indicado en el nodo xml “Element”, por lo que todos nuestros ficheros deben contener un nodo “Element” con un guid. Si no lo indicamos Vsewss construirá una feature por cada uno de los ficheros, y tendremos que modificar los ficheros a mano para volver al esado anterior.

Manifest.xml

Contiene la descripción que utilizará Sharepoint a la hora de desplegar la solución para saber dónde irá alojado cada fichero que componga la solución.

Feature.xml

Contiene la definición de las feature.

Al construir la solución Visual studio compilará los ficheros agregados en la solución. Para crear la solución de Sharepoint tendremos que seleccionar las opciones de las extensiones “Package” o “Deploy”. Esto nos creará por un lado todos los ficheros de definición de la solución y features y por otro lado los ficheros “*.wsp” que corresponde a la solución. El fichero wsp lo creará en el directorio bin.

Para crear los ficheros solution.xml, manifest.xml y las features podremos realizarlo construyendo el paquete o desde la vista “WSSP View” accesible desde el menú “View->Other Windows->WSSP View”. Esta ventana mostrará la estructura de nuestra solución.

Además de crear WebParts podremos añadir a nuestra solución otro tipo de elementos como: Definiciones de listas, contentypes, even handlers, field controls, …

Uno de los elementos más interesantes que podemos añadir es el “Template”. Esto nos creará una carpeta Template, de manera que vsewss nos copiará automáticamente al directorio “12\Template” de Sharepoint todos los ficheros que agreguemos en este directorio. Básicamente lo que hace con el elemento “Template” es mantener la sección “TemplateFiles” del fichero manifest de la solución.

Para crear una nueva feature podremos hacerlo manualmente o desde la vista “WSS View” en el botón superior “Create new feature”.

Una vez hayamos creado y compilado nuestra solución podremos desplegarla seleciconando la opción “Deploy” accesible al seleccionar con el botón derecho el fichero de proyecto de Visual Studio. Para desplegar una solución antes tendremos que indicar a Visual Studio sobre que web application lo haremos. Para hacerlo seleccionaremos la propiedades del proyecto y en la pestaña “Debug” marcaremos la opción “Start browser at URL”.

Al desplegar la solución veremos en la barra inferior de Visual Studio el progreso del despliegue. Además de la acción de despliegue podremos retraer la solución o copiar los ficheros de forma rápida mediante la opción “Quick Deploy”.

Nota: Para que podamos desplegar la solución debemos tener permisos de administración de la granja con el usuario logado.

Al trabajar con vsewss puede que nos den algunos errores al desplegar la solución muy distintos a los que nos daría si lo hiciéramos a mano.

caracteres no válidos en la ruta

Esto se produce al hacer instalaciones con idiomas distintos. Una solución es cambiar en las variables de entorno del servidor las rutas “Temps” y “Temp” por un directorio que no dependa del idioma, por ejemplo “C:\Temp”.

Could not load file or assembly

Esto se produce cuando hacemos referencia a un assembly que no está registrado en el GAC. Solo tenemos que agregarlo al GAC.

This solution contains two assemblies with the same name

Se produce cuando hemos registrado la dll manualmente en el gac. Solo hayque desinstalarla y deplegar de nuevo.

Más información acerca de errores comunes con vsewss: http://blog.csdn.net/timewolf/archive/2008/07/23/2694607.aspx

Herramientas para el desarrollo en Sharepoint

Existen muchas herramientas para el desarrollo con Sharepoint, tener una referencia acerca de las más importantes nos ahorrará tiempo y facilitará el trabajo. A continuación veremos las que considero más importantes o imprescindibles:

 

Sharepoint Designer

Será la herramientas que utilizaremos para ayudarnos a construir los diseños de nuestros webparts, páginas, masterpage, etc.

Sharepoint Designer es la evolución del FrontPage, aunque ha mejorado muchísimo.

En los siguientes post encontrareis ejemplos acerca de cómo utilizarlo:

• · WebPart de contenido con formato
• · Page Templates con ayuda del Sharepoint Designer
• · Edición rápida desde Sharepoint Designer

 

VSeWSS

Consisten en extensiones de Visual Studio para Sharepoint. Nos permiten crear los siguientes elementos:

· Definición de sitio

· Definición de listas, templates, site columns

· WebParts

· Features

Su principal ventaja es que crea una solución con los elementos del proyecto. Además podemos desplegar la solución de forma automática desde visual studio.

Empty Project

Consiste en un proyecto al que podemos agregar varios tipos de elementos Sharepoint.

Esta herramienta nos crea las estructura básica de la definición pero no la crea completamente, por lo que tendremos que terminarla manualmente editando los XMl’s

Si queremos agregar varios elementos dentro del directorio Template,( como por ejemplo un control de usuario), agregaremos un elemento del tipo “Template”.

Además para crear la solución de Sharepoint tendremos que desplegar el proyecto sobre una colección, una vez desplegada dispondremos del fichero WSP en la carpeta Debug o Release.

Ventana de exploración de la solución

Desde la ventana “WSP View” podremos visualizar la estructura de nuestra solución.

Dispondremos además de una carpeta “Pkg” no incluida en la solución donde almacenará los ficheros de definición de la solución Sharepoint. En caso que tengamos que cambiar la estructura o los nombres de los ficheros podremos retocar estos ficheros manualmente para que siga funcionando la generación automatica de la solución.

Sharepoint Solution Generator

Consiste en un asistente para crear proyectos basados en VseWSS con la definición actual de los elementos creados en nuestro portal de pruebas. Nos permite crear definiciones de sitio y de listas.

¿Para qué lo usaremos?

Lo utilizaremos para crear las soluciones de los proyectos. La definición de los elementos lo crearemos con otras herramientas.

 

SPALM - SharePoint 2007 SoftwareFactoryLite

Consiste en una extensión de Software Factory para Visual Studio. Permite gestionar el ciclo de vida de las soluciones Sharepoint mediante su integración con TFS.

SPALM estructura las aplicaciones de SharePoint en tres bloques, en función de la tipología de artefacto que contienen(Contenido, Configuración, Customizacion):

Automatiza la definición de elementos Sharepoint. Dispone además de interfaces para facilitar la definición.

¿Para qué lo usaremos?

Lo utilizaremos en proyectos complejos con varias personas en el equipo.

WspBuilder

Consiste en una aplicación de consola para crear de forma rápida soluciones Sharepoint. Dispone además de un plugin para Visual Studio 2008 que nos permite automatizar la creación de elementos como:

· Features

· Event Handlers

· Templates

· WebParts

· Custom Fields

· Web Service

· Otros…

¿Para qué lo usaremos?

Lo utilizaremos de forma similar a las extensiones VseWss.

 

Sharepoint Manager 2007

Herramienta para administrar las propiedades de los elementos de la granja.

Con Sharepoint Manager podremos editar las propiedades y características directamente en la bbdd de configuración. También podremos obtener la definición de xml de los elementos.

Lo malo es que necesitamos ejecutarlo con las credenciales del usuario con permisos a la bbdd de configuración.

 

Imtech Fields Explorer

Imtech Fields Explorer es en una herramienta desarrollada por Waldek Mastykarz. Con esta herramienta podremos:

· Exportar la definición a XML de nuestros conten types y site columns.

· Crear page layouts a partir de content types

· Crear Wrapper class en C#

Dispone además de un plugin para Visual Studio 2008. Lo malo es que solo funciona con MOSS.

Características

Exportar la definición a XML de nuestros conten types y site columns.

Podemos navegar por la jerarquía de contenttypes y exportar a xml su definición.

Esto es especialmente útil cuando estamos construyendo una feature a partir de nuestro sitio de pruebas.

Crear page layouts a partir de content types

Field Explorer automatiza la creación de page layouts de nuestros content types.

Crear Wrapper class en C#

Podemos crear clases en C# con los GUIDs de los campos de nuestros contentypes y listas. Esto está bien cuando tenemos un único entorno, para poderlo aplicar con una solución que esté con varios entornos (desarrollo, integración, etc.) podemos crear una dll con el mismo nombre para cada entorno, de manera que el proyecto solo se compile una vez independientemente de donde se despliegue.

¿Para qué lo usaremos?

Usaremos principalmente la generación de wrappers de nuestros elementos.

La definición del XML de los elementos lo utilizaremos para ayudarnos a crear las soluciones de VseWSS.

Feature Generator

Herramienta todavía en desarrollo que nos permite crear las definiciones de distintos tipos de elementos de Sharepoint a partir de un sitio existente. Tiene algunos fallos pero permite crear definiciones de varios elementos al mismo tiempo.

¿Para qué lo usaremos?

Lo utilizaremos para definir los xml de los elementos que componen nuestra solución.

 

U2U CAML Query Builder

La utilizaremos para construir nuestras consultas CAML. Es importante que al probarlo quitemos los nodos “Query” que nos genera.

¿Para qué lo usaremos?

Lo utilizaremos para crear nuestras consultas CAML.

SharePoint Content Deployment Wizard

Con esta herramienta podremos exportar el contenido de nuestro sitio para moverlo a otra instalación.

http://www.codeplex.com/SPDeploymentWizard

 

NET Reflector

Herramienta imprescindible que nos permitirá desensamblar las librerías de .net y entender el funcionamiento de las páginas, controles y webparts estándar.

WebPart de contenido con formato

En este post veremos cómo definir nuestro propio WebPart de contenido con un formato diferente al habitual de tablas. Todo esto sin tirar una línea de código ya que solo nos centraremos en definir cómo presentar el contenido.

Supongamos que disponemos de una lista de Sharepoint con las noticias de la intranet y queremos disponer de una vista de las últimas noticias en la página principal.

Lo primero que haremos será abrir una página de nuestro sitio con Sharepoint Designer y agregaremos un DataFormWebPart. Seleccionaremos nuestra lista de noticias y los campos que queremos visualizar. En este ejemplo he creado una lista del tipo “Anuncios”.

Para agregar el DataFormWebPart realizaremos lo siguiente:

En vista diseño, en el menú “Insertar” seleccionaremos “Controles de Sharepoint” y luego “Vista de datos”.

A continuación iremos a la ventana de “biblioteca de orígenes de datos” seleccionaremos la lista de la que queremos obtener la información y pulsaremos en la opción “Mostrar datos”.

Esta opción nos mostrará los campos disponibles en la lista. Seleccionaremos los campos que deseamos visualizar en nuestra vista (o los que deseamos disponer) y seleccionamos “Insertar los campos seleccionados como” y “Vista de varios elementos”.

Una vez agregado cambiaremos la forma de presentar el contenido modificando el XSL del DataFormWebPart. Seleccionaremos el WebPart con Sharepoint Designer y visualizaremos el código de la página. Buscaremos la sección “<xsl:template name="dvt_1.rowview">” que corresponde al código que renderizará el WebPart para cada ítem de la lista de noticias, y tocaremos la sección “<xsl:template name="dvt_1">” que corresponde con la cabecera y la definición de la tabla.

Solo tendremos que adaptar estas secciones para que muestre el contenido con el formato que deseemos.

En mi ejemplo he dejado el siguiente código en el DataFormWebPart:

<xsl:template name="dvt_1">

<xsl:variable name="dvt_StyleName">Table</xsl:variable>

<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row"/>

<table border="0" width="100%" cellpadding="2" cellspacing="0">

<tr valign="top">

<xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">

<th class="ms-vh" width="1%" nowrap="nowrap"></th>

</xsl:if>

</tr>

<xsl:call-template name="dvt_1.body">

<xsl:with-param name="Rows" select="$Rows"/>

</xsl:call-template>

</table>

</xsl:template>

<xsl:template name="dvt_1.body">

<xsl:param name="Rows"/>

<xsl:for-each select="$Rows">

<xsl:call-template name="dvt_1.rowview"/>

</xsl:for-each>

</xsl:template>

<xsl:template name="dvt_1.rowview">

<tr>

<xsl:if test="position() mod 2 = 1">

<xsl:attribute name="class">ms-alternating</xsl:attribute>

</xsl:if>

<td>

<table>

<tr>

<td class="ms-vb" style="font-weight:bold">

<a>

<xsl:attribute name="href" >

<xsl:value-of select="concat('/Lists/Noticias/DispForm.aspx?ID=', @ID)"></xsl:value-of>

</xsl:attribute>

<xsl:value-of select="@Title"/>

</a>

</td>

</tr>

<tr>

<td class="ms-vb" style="font-style:italic">

<xsl:value-of select="@Resumen" disable-output-escaping="yes"/>

</td>

<td class="ms-vb">

<xsl:value-of select="ddwrt:FormatDate(string(@Created), 3082, 5)"/>

</td>

</tr>

</table>

</td>

</tr>

</xsl:template>

Al final conseguimos el siguiente aspecto:

 

Fijaros que el tag “<xsl:value-of select>” renderiza un campo, variable o función de XSL.

Para conseguir que el título vaya al Dispform del ítem, he agregado el siguiente códogio:

<a>

<xsl:attribute name="href" >

<xsl:value-of select="concat('/Lists/Noticias/DispForm.aspx?ID=', @ID)"></xsl:value-of>

</xsl:attribute>

<xsl:value-of select="@Title"/>

</a>

Mediante xsl he modificado el atributo href del hyperlink para que contenga la url compuesta al concatenar la url del formulario DispForm con el ID del ítem actual.

Una vez finalizada la edición de nuestro webpart lo exportaremos a un fichero del tipo “.webpart”. Esto lo podemos hacer guardamos la página y seleccionando la opción “exportar” accesible desde el navegador en modo edición.

O bien desde Sharepoint Designer seleccionaremos el WebPart en modo diseño u seleccionaremos “Archivo”, “Exportar”, Guardar elemento web en”, “Archivo”.

El archivo Webpart que nos genere contendrá la definición del webpart de contenidos con nuestro xsl formateado. Ahora solo tendremos que subirlo a nuestra colección desde la opción de “Elementos web” en la página de configuración del sitio y ya estará disponible para agregarlo en cualquiera de nuestras páginas.

Si quisiéramos moverlo a otro colección o web application, solo tendríamos que abrir el fichero Webpart generado y editar el parámetro “ListID” con el GUID de la instancia de nuestra lista.

Modificar la apariencia de nuestro sitio

Continuando con el hilo de los post anteriores “Quick reference Sharepoint” hablaremos ahora de una de las cosas que tendremos que hacer tarde o temprano en un proyecto con Sharepoint, modificar la apariencia de nuestro sitio.

Sharepoint nos proporciona varios mecanismos que aprovechan la infraestructura de ASP.NET 2. : Los temas, masterpages, las colecciones de hojas de estilo y de imágenes, los elementos de navegación.

Masterpage

Las masterpages consisten en plantillas que definen cómo se distribuirá el contenido en una página pero sin llegar a conocer el contenido ni su comportamiento. Sharepoint nos proporciona varias masterpage en función del tipo de plantilla de sitio que elijamos.

Para alojar los ficheros masterpage disponemos de una galería por cada colección de sitios, lo podemos encontrar en la conficugarción del sitio raíz en la opción “Páginas maestras” o en la ruta “/_catlagos/masterpage/”.

Si abrimos Sharepoint Designer y observamos la página default.aspx, veremos cómo está haciendo referencia a la masterpage por defecto mediante la url “~masterurl/default.master”. El path “~masterurl” indica el path a la galería de páginas maestras.

<%@ Page language="C#" MasterPageFile="~masterurl/default.master" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document" %>

En el siguiente artículo encontramos la distribución de cada uno de los contentplaceholder de la masterpage por defecto: Default content placeholders in a SharePoint master page

Provisionando una masterpage

Para modificar una masterpage tenemos varios mecanismos:

· Convirtiendo el fichero en unghosted

· Provisionando la masterpage en la galería de páginas maestras.

· Alojando la masterpage en la definición de la plantilla de sitio

· Desde una feature

Convirtiendo el fichero en unghosted

Esta es la manera más fácil y rápida, consiste en crear una instancia del fichero en la bbdd de contenidos de manera que en lugar de instanciarse desde el sistema de ficheros del frontal se instancia a partir de la bbdd de contenidos.

Esta es una práctica poco recomendable para implantaciones serias, solo las utilizaremos en prototipos. En el artículo Ghosted o unghosted, ¿Quien corre mas? podéis encontrar los motivos por los que no son recomendables las ficheros unghosted.

Provisionando la masterpage en la galería de páginas maestras.

Consiste en cargar un fichero masterpage directamente en la galería de páginas maestras. Esta galería consiste euna librería de documentos , por lo quela podremos provisionar manualmente o mediante features o código.

Alojando la masterpage en la definición de la plantilla de sitio

Consiste en definir una masterpage para todos los sitios que se creen a partir de una plantilla, de manera que no haya que subirla manualmente en cada colección.

En el siguiente artículo encontramos un tutorial acerca de cómo hacerlo: How to Create and Store Master Pages on the Server for Use with Site Collections

Desde una feature

Para provisionarlo desde una feature:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Module Name="AddMasters" Url="_catalogs/MasterPage" >
        <File Url="MyDefault.master" Type="GhostableInLibrary"
          IgnoreIfAlreadyExists="True">

        </File>
        <File Url="custom.master" Type="GhostableInLibrary"
          IgnoreIfAlreadyExists="True"/>

        </File>
  </Module>
</Elements>

Podemos encontrar un ejemplo en: Create a Feature: Master Pages for Site Collections

Establecer la masterpage

A la hora de provisionar los ficheros debemos pensar que cada sitio tiene su propia galería de páginas maestras, por lo que podemos hacer que cada sub-sitio tenga su propia apariencia.

Para establecer la masterpage por defecto del sitio podemos o bien indicarlo con Sharepoint Designer seleccionando el fichero y con el botón derecho “Establecer como página principal predeterminada”, o bien utilizando Sharepoint Manager seleccionando el sitio y editando la propiedad “CustomMasterUrl”.

Mediante programación podemos hacer lo siguiente:

CurrentWeb.MasterUrl = "/_catalogs/masterpage/MyDefault.master";
CurrentWeb.CustomMasterUrl = "/_catalogs/masterpage/custom.master";
CurrentWeb.Update();

Si tenemos habilitada la característica de publicación

Dispondremos de funcionalidades adicionales que nos facilitarán el mantenimiento de estilos en una jerarquía de sitios grande.

Dispondremos de la opción “Página maestra” en la página de configuración del sitio en la sección “Aspecto”, desde donde podremos establecer la masterpage por defecto. Además disfrutaremos de la posibilidad de herencia de de manera que se apliquen los cambios a todos los subsitios.

Distribución de contentplaceholder

Cuando hagamos personalizaciones que cambien drásticamente la apariencia lo más fácil es mantener los placeholders estándar para que no se produzca ningún error inesperado, pero los podremos mantener ocultos mediante la propiedad “visibility”.

Masterpage de Application pages

Las páginas del tipo Application pages no podrán utilizar la masterpage default.master. Por defecto utilizan Application.master alojada en la ruta “_layout”.

Hojas de estilo

Sharepoint utiliza por defecto la hoja de estilos CORE.css en el directorio “12\Templates\Layouts\{Idioma}\Styles”. No es recomendable editar directamente este fichero ya que es bastante complejo, es común para todos los sitios y puede que se pierdan los cambios al instalar actualizaciones.

Para establecer nuestras propias hojas de estilo podremos indicarlo mediante el tag de la masterpage “<SharePoint:CssLink>”. Podemos establecer distintas hojas de estilo mediante este elemento y su propiedad “DefaultUrl” donde indicaremos la url de nuestra hoja de estilo.

<SharePoint:CssLink runat="server" DefaultUrl="<% $SPUrl:~SiteCollection/_layouts/styles/prueba.css%>" />

También podemos especificar más hojas de estilos mediante el uso de “<SharePoint:CssRegistration>” que registrará las hojas de estilo en orden alfabético antes de renderizar las hojas primarias, por defecto y altérnate.

En el siguiente artículo podemos encontrar una completa referencia sobre los estilos por defecto: CSS Reference Chart for SharePoint 2007

Si tenemos habilitada la característica de publicación

Desde la opción “Página maestra” en la sección “Aspecto” de la página de configuración del sitio podremos indicar nuestros propios ficheros de hoja de estilo sin tener que modificar la masterpage y podremos aplicarlo a todos los subsitios.

Dispondremos además una librearía de hojas de estilo donde almacenar nuestras css y poder establecerlas en la opción mencionada anteriormente.

Desde la masterpage también podremos utilizar los elementos “<SharePoint:CssLink>” y “<SharePoint:CssRegistration>” pero indicando en la url que utilice las hojas de estilo de la galería de estilos.

<SharePoint:CssRegistration name=”<% $SPUrl:~SiteCollection/Style Library/~language/Core Styles/ prueba.css%>” runat=”server”/>

Temas

Nos permiten cambiar la apariencia de nuestros sitios sin cambiar la distribución ni realizar modificaciones en las páginas. Los temas permiten cambiar el estilo, los colores y las imágenes asociadas a los estilos.

Para cambiar el tema de nuestro sitio podremos realizarlo desde el navegador en la opción “Tema del sitio” en la página de configuración del sitio.

Para crear nuevos temas podemos fijarnos de los existentes y extenderlos o adaptarlos. En la carpeta “12\Template\themes” estarán alojados todos los temas disponibles. Copiais una carpeta de un tema existente y lo renombráis pero en mayúsculas. Dentro existirá un fichero con extensión “.inf” lo renombrais (también en mayúsculas” con el mismo nombre que la carpeta que habéis creado. Abrís el fichero “.inf” y modificáis los títulos.

A continuación ya podéis editar vuestro tema incluyendo imágenes y hojas de estilo.

Una vez terminado tendréis que registrar el estilo en el fichero “\12\TEMPLATE\LAYOUTS\{Idioma}\SPTHEMES.XML”.

En el siguiente enlace podréis encontrar un ejemplo más detallado: http://www.sharepointblogs.com/tigirry/archive/2007/07/03/custom-site-theme-for-sharepoint-2007-moss-2007-and-wss-3-0.aspx

Operaciones con Stsadm

Siguiendo con el hilo del post anterior para ayudar en la introducción con Sharepoint, os dejo un enlace con las operaciones que se pueden realizar con Stsadm por categorías, creo que os será más útil que enumeradas alfabéticamente.

http://technet.microsoft.com/en-us/library/cc262643.aspx