miércoles, 14 de enero de 2009

This Page has been modified since you opened it

El webpart que estaba construyendo estaba extendiendo las funcionalidades de búsqueda de MOSS y al hacer un submit a la página de resultado me daba el error “This Page has been modified since you opened it. You must open the page again.” o “Se ha modificado esta página desde que la abrió. Debe volver a abrirla.”. Lo curioso es que encima no dejaba ninguna marca en el log de Sharepoint ni de windows, por lo que no sabes exactamente que está pasando.

Al final después de mucho batallar, me fijé que el control estándar que estaba extendiendo llamaba a dos funciones javascript al hacer el submit

… onclick="ResetPageHashCode();WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions( …

Al principio no le dí mucha importancia, pero justo cuando estaba probando con Fidler para comparar lo que enviaba el control estándar con el mío, me di cuenta que borrando el valor del parámetro post “MSO_PageHashCode” dejaba de dar el error. Qué curioso!!!, resulta que mirando el código de la función “ResetPageHashCode” borra este elemento de la página antes de hacer un submit.

Efectivamente añadiendo esta llamada antes de hacer un submit conseguí arreglar mi control, aunque en mi caso tuve que tocarla ya que no me llegaba a funcionar del todo:

function ResetPageHashCode()
{
var f = document.forms[0];
if (null != f && null != f.elements['MSO_PageHashCode'])
f.elements['MSO_PageHashCode'].value = "";

_spFormOnSubmitCalled = false;
}

<asp:Button ID="ASB_BS_SRCH_1" runat="server" Text="Buscar" CssClass="boton" OnClientClick="ResetPageHashCode();Buscar();" />

No puedo asegurar que sea la solución para todos los casos en los que ocurre este error ya que se proponen muchas soluciones, pero en mi caso ha funcionado.

Otras soluciones a este error:

Resolution: MOSS: This Page has been modified since you opened it. You must open the page again.

SharePoint Errors, Warnings and Problems Collection

This Page has been modified since you opened it. You must open the page again.

Finally: A Federation Search results page that doesn't give me the need to "Refresh Page" before I can see the results

martes, 13 de enero de 2009

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:

 

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.

domingo, 11 de enero de 2009

Ajax sobre Sharepoint

Continuando con la temática de este mes acerca de dar una introducción al desarrollo sobre Sharepoint, nos queda por ver como montar Ajax en Sharepoint.

Ya se ha hablado mucho sobre este tema por lo que me limitaré a dejar una referencia rápida:

Lo primero será instalar las extensiones de AJAX, si tenemos el Framework 3.5 no será necesario instalarlo, en caso contrario tendremos que descargar el kit “ASP.NET 2.0 AJAX Extensions”.

Una vez instalado tendremos que configurar nuestro web.config:

Verificaremos el nº de versión de la librearía “System.web.extension”, para verlo podremos visualizarlo desde el GAC en “c:\windows\assembly”.

A continuación abriremos nuestros web.config, por defecto están alojados en la carpeta “c:\inetpub\wwwroot\wss\VirtualDirectories”.

1. Añadiremos un nuevo sectionGroup en la zona configSections:

<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
          <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
        <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
          <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere" />
          <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
        </sectionGroup>
      </sectionGroup>
    </sectionGroup>

2.Añadimos una sección controls en la sección “pages”:

<pages>
      <controls>
        <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      </controls>
</pages>

3. Añadimos el siguiente assemblie en la sección de assemblyes:

<assemblies>
       <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</assemblies>

4. Registramos los manejadores:

<httpHandlers>
      <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>
</httpHandlers>

6. Añadimos el módulo de Ajax en la sección httpModules:

<httpModules>
      <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </httpModules>

7. Permitimos que los controles incluidos en la librería de Ajax puedan ejecutarse en Sahrepoint:

<SafeControls>
      <SafeControl Assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Web.UI" TypeName="*" Safe="True" />
</SafeControls>

Una vez registrado, verificaremos que todo funciona correctamente. Si nos hemos dejado algo o lo hemos registrado mal puede que nos de un error de ASP.NET al entrar en cualquier página del web application.

Nos quedaría por registrar el scriptmanager en las páginas para que podamos utilizar los controles de Ajax. Podremos hacerlo de varias formas:

  • Incluyéndolo en la masterpage
  • Auto-registrándolo desde un webpart.

Incluyéndolo en la masterpage

Consiste en modificar la masterpage para incluir el scriptmanager. Este caso es válido siempre que tengamos la misma masterpage en todos los subsitios, en caso de tener una jerarquí de sitios muy grande y que encima no hereden del padre tendremos que recurrir al autoregistro desde el propio webpart.

En el post anterior “Modificar la apariencia de nuestro sitio” vimos como modificar nuestra masterpage (por lo que no detallaremos como realizar la modificación).

Abriremos entonces la masterpage, y añadiremos el siguiente código cerca de la definición de <WebPartPages:SPWebPartManager>  :

<asp:ScriptManager runat="server" ID="ScriptManager1"></asp:ScriptManager>

Si quisiéramos utilizar el control UpdatePanel tendremos que registrar el siguiente script en la página:

<script type='text/javascript'>_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;</script>

Auto-registrándolo desde un webpart

Si queremos asegurarnos que nuestro webpart con ajax va a funcionar desde cualquier página podremos recurrir a registrar el scriptmanager mediante programación añadiendo el siguiente código en el evento Oninit:

 

protected override void OnInit(EventArgs e) {

base.OnInit(e);

//get the existing ScriptManager if it exists on the page

_AjaxManager = ScriptManager.GetCurrent(this.Page);

if (_AjaxManager == null)   {

//create new ScriptManager and EnablePartialRendering

  _AjaxManager = new ScriptManager();

  _AjaxManager.EnablePartialRendering = true;

// Fix problem with postbacks and form actions (DevDiv 55525)

Page.ClientScript.RegisterStartupScript(typeof(AjaxBasePart), this.ID, "_spOriginalFormAction = document.forms[0].action;", true);

//tag:"form" att:"onsubmit" val:"return _spFormOnSubmitWrapper()" blocks async postbacks after the first one

//not calling "_spFormOnSubmitWrapper()" breaks all postbacks

//returning true all the time, somewhat defeats the purpose of the _spFormOnSubmitWrapper() which is to block repetitive postbacks, but it allows MS AJAX Extensions to work properly

//its a hack that hopefully has minimal effect

if (this.Page.Form != null)   {

string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];

if (!string.IsNullOrEmpty(formOnSubmitAtt) && formOnSubmitAtt == "return _spFormOnSubmitWrapper();")  {

this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";

  }

//add the ScriptManager as the first control in the Page.Form//I don't think this actually matters, but I did it to be consistent with how you are supposed to place the ScriptManager when used declaritevly

this.Page.Form.Controls.AddAt(0, _AjaxManager);

               }

            }

}

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.

sábado, 10 de enero de 2009

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

miércoles, 7 de enero de 2009

Habilitar intellisense para Xml de definición de Sharepoint

Uno de los problemas que nos encontramos al desarrollar componentes para Sharepoint es que no disponemos de una herramienta gráfica completa para definirlos, de manera que tenemos que ser nosotros los que editemos manualmente los xml de definición de nuestras features, contentypes, esquemas, etc...

Utilizaremos la ayuda de intellisense de Visual Studio para componer estos Xml’s. Para habilitarlo abriremos nuestro xml y en la ventana de propiedades en la propiedad “Schemas” seleccionaremos el icono de más detalle “…”.

Al seleccionarlo se abrirá una ventana con los esquemas predefinidos para el esquema “http://schemas.microsoft.com/sharepoint “.

A continuación dejaremos solo el fichero wss.xsd alojado en el directorio de sharepoint “Template\xml\wss.xsd”. Para desmarcar los ficheros seleccionaremos el valor “Automatic” en la columna “Use”.

Una vez seleccionado aceptamos las modificaciones y ya podremos disfrutar de la ayuda de Microsoft para completar nuestro xml.

lunes, 5 de enero de 2009

Novedades en Windows SharePoint Services 4.0?

Recientemente Michael Greth ha publicado dos post donde nos comenta algunas de las novedades que incorporará WSS 4.

Custom List Views and WSS 4.0’s XSLT-based List View

Custom Field Types and WSS 4.0’s XSLT-based Field Type

Según comenta Michael Greth, Microsoft ha publicado varios artículos (The CustomListView rule in Pre-Upgrade Checker can warn that customized list views that will not be upgraded y La regla CustomFieldType en Comprobador previas a la actualización en el Service Pack 2 de Windows SharePoint Services 3.0 puede advertir que campo personalizado no se actualizarán tipos) acerca de posibles errores con los list view y algunos customfields al actualizar a la nueva versión de Sharepoint Service.

De estos artículos Michael saca las siguientes conclusiones acerca de la siguiente versión WSS 4:

  • El List View WebPart evoluciona a una nueva versión XSLT-based List View Web Part con nuevas funcionalidades como la mejora en la personalización con Sharepoint Designer, formatos condicionales y mejoras en la experiencia del desarrollo con XSLT.
  • Aparecerá un nuevo tipo de campo llamada XSLT-based field type.

Bueno, veremos que pasa en estos meses que llegan, lo que si es seguro es que todos estamos deseando tener en nuestras manos la nueva versión.