Ya soy MCTS en: WSS 3.0 – Application Development!

Hace unas horas he pasado el examen 70-541 MCTS: Microsoft Windows SharePoint Services 3.0 - Application Development. Han sido unos cuantos meses de estudio que han tenido su recompensa. Sólo una buena noticia que quería compartir.

Como resumen les digo que es una certificación que vale la pena encarar, ya que profundiza en los conceptos más importantes de SharePoint, algo imprescindible para los que nos dedicamos a esto.

Respecto a los materiales les comento que preparamos la certificación fundamentalmente con el libro Inside Microsoft® Windows® SharePoint® Services 3.0,exceptuando el capítulo de Ajax y buscando algunos contenidos que no estaban cubiertos por el libro. Por si les interesa, algunos de los puntos los resumimos en una serie de artículos que pueden encontrar aquí: http://surpoint.blogspot.com/search/label/70-541.

Hasta la próxima y no dejen de encarar certificaciones, "estudiar" sólo genera ventajas y satisfacciones...

Leer más...

Manejadores de eventos en SharePoint

Los manejadores de eventos constituyen una de las funcionalidades más sencillas de utilizar a la hora de extender nuestras aplicaciones de SharePoint a través del desarrollo. Básicamente permiten agregar comportamiento a nuestra aplicación e implementar reglas de negocio.
Este post pretender describir todos los aspectos de esta técnica, desde la parte conceptual hasta la parte de código con algunos ejemplos en Visual Studio. Está basado en el webcast que dicté el 16/12/2009. Como siempre, espero que les sea útil.

WebCast

Si desean ver el webcast, pueden hacerlo desde:

• ManejadoresEventos_Formato_LM
• ManejadoresEventos_Formatos_WMV

Si desean ver la presentación que utilicé en el webcast pueden verla aquí:

Manejadores de eventos en SharePoint

View more presentations from jpussacq.

Introducción

Los manejadores de eventos permiten extender a través de desarrollo una aplicación SharePoint. Agregan comportamiento a listas e ítems entre otros. Un manejador de evento se ejecuta automáticamente como respuesta a un evento como agregar una columna en una lista o modificar un ítem en una lista. Pueden servir para:

• Validaciones de datos
• Control de integridad referencial
• Control de unicidad
• Ejecución de procesos de negocio
• Lo que no puede resolver un campo calculado
• Protección de la parametrización
• Cambios en la seguridad
• Controles de seguridad funcional

Si conocen triggers de base de datos, verán que tienen un cierto parecido. Si bien son más potentes, podríamos decir que todo lo que se hace con un trigger, puede hacerse con un evento en SharePoint. Esto puede darles una idea del potencial de esta técnica.

¿Qué eventos maneja SharePoint?

El siguiente gráfico resume los eventos soportados por SP. Pueden observar que existen eventos a nivel de ítems de lista (los que se parecen a los triggers), pero también eventos a nivel de lista, sitio, colección de sitio o característica:

Imaginen lo que se puede hacer...

A continuación les daré algunas ideas de lo que se puede hacer con eventos. Son sólo ideas. Es mucho más lo que se puede hacer, pero les servirá de inspiración. Lo importante es que realmente resuelven temas que no existen en SP "out of the box", en forma bastante sencilla:

Tipos de eventos ¿antes o después? ¿sincrónicos o a-sincrónicos?

Es importante aclarar que existen dos tipos de eventos, los que se ejecutan antes de que se efectúe el "commit" de la transacción en la base de datos de contenido y los que se disparan luego de que se ejecute el "commit". Los primeros son sincrónicos, los segundos a-sincrónicos (en SP 2007, en 2010 es configurable).

El siguiente es el mapa completo de todos los eventos que SP 2007 maneja, incluye sus variantes sincrónicas y a-sincrónicas:

Evento o Flujo de Trabajo

Por sugerencia de Angel Acha Lizama luego del webcast, me pareció importante incluir una breve comparación entre Eventos y Flujos de trabajo porque son técnicas que tienen algún punto en común y el lector podría encontrar difícil la decisión de cuál usar en cada caso.
En líneas generales tengan en cuenta que un flujo de trabajo suele tener interacción con los usuarios a través de pantallas, puede perdurar en el tiempo (días, semanas, meses, etc.) y requiere persistir la información.
Un evento responde a una transacción y se ejecuta en el momento, no tiene pantallas asociadas, su duración es breve y no debe ser retomado luego de un tiempo, como sucede con un flujo de trabajo.
Les dejo este enlace que me pasó Angel, si quieren ampliar el tema: http://msdn.microsoft.com/en-us/library/ee413841.aspx

Pasos para crear un evento

La siguiente lámina muestras los pasos que se deben seguir para crear un evento. No estamos usando ninguna herramienta, ni extensión para SharePoint que nos facilite la creación, con el fin de explicar los conceptos básicos.

Paso 1: crear el proyecto

Si necesitan ayuda con este paso, les dejo este enlace que lo explica en forma detallada: http://sharepoint-puntodeencuentro.blogspot.com/2008/09/registrar-un-evento-mediante-una.html

Paso 2: definición de una clase

Ejemplo muy sencillo de definición de clase, cuyo objetivo es impedir que un administrador agregue columnas en una lista:

Paso 3: binding

Existen dos formas de vincular la definición de una clase de un evento a una entidad (lista, característica, etc): 1) a través de XML dentro de una característica y 2) programáticamente. Estas dos formas apuntan a objetivos distintos. A continuación veremos dos ejemplos:

Binding XML

Observaciones

• Sólo pueden registrarse en características cuyo ámbito sea «site».
• Sólo se puede registrar el evento para un «tipo de lista», no para una lista en particular.
• También se puede registrar eventos para tipos de contenidos o features.
• «SequenceNumber» indica el órden cuándo tengo más de un evento.

Binding en forma programática

A diferencia de la opción vía XML, nos permite vincular un evento a una lista específica, en lugar de a un tipo de lista. Ejemplo:

Demostraciones

A continuación dejamos el código fuente de las demostraciones que presentamos en el webcast. Tengan en cuenta que se trata de un prototipo, no una aplicación final, por lo cual nos hemos tomados algunas licencias para escribir código y notarán algunas desprolijidades.

Demo 1: completando una columna en un evento de ítem

Este ejemplo muestra como completar un campo dentro de un evento. En el código pueden ver dos ejemplo, un caso común para el campo "Proyecto" y otro para un campo de tipo URL, el campo "Actividad".

Demo 2: validando integridad en un evento de ítem

El siguiente ejemplo muestra cómo validar "unicidad" de una columna y cancelar la operación, emitiendo un mensaje al usuario, en caso que no se cumpla esta restricción.





 

Demo 3: ejecutando un proceso de negocio en un evento de ítem

Este ejemplo muestra cómo a partir de la creación de un ítem, se dispara la creación de ítems en otra lista. Muestra cómo se leen los datos de la lista origen, cómo se recorren esos datos y como se crean los ítems en la lista destino.











 

Demo 4: ejecutando un evento al instalar una característica

Este último ejemplo nos muestra un ejemplo de evento para una característica. El objetivo es hacer cambios de estilos en SharePoint. Para una explicación más amplia pueden consultar este enlace: http://surpoint.blogspot.com/2009/07/cambios-de-estilos-en-sharepoint.html.

Paso 4: instalar

No voy a bajar a detalle con este paso, pero quería dejarles el contenido del ."bat" en dónde se muestra la instalación de la dll en la GAC, el copiado de los archivos XML y la instalación de la característica en SharePoint:

SharePoint 2010

El siguiente gráfico resume las novedades en SharePoint 2010 respecto a eventos. Lo más importante es saber que hay algunos eventos nuevos, pero fundamentalmente que los eventos "before" pueden ser sincrónicos o a-sincrónicos. Al final de este artículo les dejo un enlace por si necesitan ampliar este tema.

Un tema relacionado que no debemos dejar pasar es que SP 2010 agrega el concepto de validación de campos "Out of the box". Esto es mucho más sencillo de usar que programar un evento para validar de datos. La validación se arma con fórmulas similares a la de los campos calculados y es posible especificar el mensaje de error para el usuario. Estas validaciones se pueden crear a nivel de columnas de sitio, o columnas dentro de una lista.

Fin

Aquí termino. Espero que les haya sido útil y lo hayan disfrutado. Hasta la próxima!

Bibliografía y enlaces interesantes

Libros

• Inside Microsoft Windows SharePoint Services 3.0 (Chapter 6)
• By Ted Pattisonand & Daniel Larson (Microsoft Press)
  
  

Artículos

• MSDN: http://msdn.microsoft.com/en-us/magazine/cc163318.aspx (Events in SharePoint 2007)
• MSDN SharePoint 2010: http://msdn.microsoft.com/en-us/library/ee540025(office.14).aspxaspx (Events Improvements)
• Surpoint: http://surpoint.blogspot.com/search/label/Eventos

Leer más...

Trabajando con tipos de contenido en SharePoint

Según Microsoft TechNet un tipo de contenido define los atributos de un elemento de la lista, documento o carpeta. Cada tipo de contenido puede especificar: propiedades, flujos de trabajo, eventos, plantillas de documentos y otras características personalizadas.

Una explicación mía, menos ortodoxa, define a los tipos de contenido como algo muy parecido a los subtipos y supertipos de un modelo de entidad relación. El clásico ejemplo de Empleado Contratado y Empleado en Relación de dependencia puede definirse en forma muy simple en SharePoint, logrando con muy poco esfuerzo pantallas para cada tipo de empleado con sus columnas asociadas.

Este artículo trata sobre la creación de tipos de contenido en forma programática…

Introducción

Los tipos de contenidos trabajan bajo el principio de la herencia. No es posible crear un tipo de contenido desde cero, debe heredar de un tipo de contenido base. Una primera definición al crear un tipo de contenido consiste en definir si será utilizado en listas o librerías de documentos. Los tipos de contenido para librerías de documentos soportan como adicional la posibilidad de especificar plantillas de documentos, por ejemplo en Word.

Como punto final, es importante saber que los tipos de contenido pueden definir también el comportamiento, a través de flujos de trabajo y manejadores de eventos.

Crear un tipo de contenido usando CAML

Para crear un tipo de contenido es necesario haber creado previamente las columnas de sitio. Para cada columna de sitio que incluiremos en nuestro tipo de contenido, debemos incluir un elemento FIELDREF, que defina el GUID y el NAME de la columna, Opcionalmente podemos definir un DISPLAYNAME distinto a NAME.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <ContentType ID=""

    Name="EmpleadoContratado"

    Description="Crear un nuevo empleado contratado"

    Version="0"

    Group="Tipos de contenido de SurPoint" >

    <FieldRefs>

     <FieldRef ID="{}" Name="Title" DisplayName="Empleado" Sealed="TRUE" />

     <FieldRef ID="{}" Name="Legajo" DisplayName="Legajo" />

    </FieldRefs>

  </ContentType>

</Elements>

El ID especifica el identificador del tipo de contenido y está diseñado para ser recursivo. Cada identificador de tipo de contenido contiene el identificador del tipo de contenido primario, el cual contiene a su vez el identificador del elemento primario de dicho tipo de contenido y así sucesivamente hasta llegar al identificador de tipo de contenido del sistema, inclusive. Mediante el análisis del identificador de tipo de contenido, puede determinar qué tipos de contenido hereda el tipo de contenido y cómo están relacionados dos tipos de contenido [MSDN: Identificadores de tipo de contenido].

La siguiente imagen muestra la jerarquía de tipos de contenido. Más información en: MSDN: Jerarquía de tipos de contenido base.

Asociar un tipo de contenido a una lista

Se puede asociar uno o varios tipos de contenido a una lista en el momento de la definición de la misma utilizando el elemento ContentTypes:

<ContentTypes>

  <ContentTypeRef ID = "Text">

    <Folder

     TargetName="Text">

    </Folder>

  </ContentTypeRef>

  ...

</ContentTypes>

ContentTypeRef establece la referencia al tipo de contenido que queremos asociar con la lista.

Control de cambios en tipos de contenido

Pueden establecer un tipo de contenido como sólo lectura, lo cual genera una advertencia para el usuario, pero no impiden que cambie este parámetro.

Otra alternativa es sellar los tipos de contenido (atributo Sealed), lo cual impide los cambios. El usuario debería ser administrador de la colección de sitios para modificar este parámetro.

Más información en: MSDN: Control de cambio de tipos de contenido

Links interesantes

• MSDN: Introducción a los tipos de contenido
• MSDN: Elemento ContentType (ContentType)
• MSDN: Identificadores de tipo de contenido
• MSDN: Jerarquía de tipos de contenido base
• MSDN: Control de cambio de tipos de contenido
• MSDN: Elemento ContentTypes

FIN

Como verán, el tema es bastante amplio. Finalizo este artículo aquí para dejarles una primera introducción como base.

Como siempre, espero que les sea útil y que lo disfruten..

Leer más...

Crear columnas de sitio en una Feature

Las columnas de sitio son un mecanismo provisto por WSS 3.0 para reusar campos de listas o tipos de contenido.

Características:

• Visibilidad: una columna definida en una colección de sitios puede ser vista por todos los sitios de la colección.
• Herencia:
  • Alta: al agregar una columna de sitio en una lista nos aseguramos contar de entrada con los mismos atributos. Los cambios que realicemos posteriormente en la la lista, sólo son aplicables a la lista en donde agregamos la columna.
  • Baja: no se puede eliminar una columna de sitio si está siendo usada en alguna lista o tipo de contenido.
  • Modificación: si se realizan cambios en una columna de sitio, se puede elegir que los mismo sean propagados a los hijos.

Definir la columna de sitio en una Feature

Las columnas de sitio pueden ser definidas utilizando CAML. Ejemplo:

<Field ID="{}"

  Name="Nombre"

  SourceID=http://schemas.microsoft.com/sharepoint/v3

  StaticName="Nombre"

  DisplayName="$Resources:core,Nombre;"

  Type="Text">

</Field>

La siguiente lista enumera los atributos posibles del elemento Field. Para mayor información consultar MSDN: Elemento Field (Definición):

• Aggregation = "sum" | "count" | "average" | "min" | "max" | "merge" | "plaintext" | "first" | "last"
• AllowDeletion = "TRUE" | "FALSE"
• AllowHyperlink = "TRUE" | "FALSE"
• AllowMultiVote = "TRUE" | "FALSE"
• AppendOnly = "TRUE" | "FALSE"
• AuthoringInfo = "Text"
• BaseType = "Integer" | "Text"
• CalType = "Integer"
• CanToggleHidden = "TRUE" | "FALSE"
• ClassInfo = "Text"
• ColName = "Text"
• Commas = "TRUE" | "FALSE"
• Decimals = "Integer"
• Description = "Text"
• Dir = "Text"
• DisplaceOnUpgrade = "TRUE" | "FALSE"
• DisplayImage = "Text"
• DisplayName = "Text"
• DisplayNameSrcField = "Text"
• Div = "Number"
• EnableLookup = "TRUE" | "FALSE"
• ExceptionImage = "Text"
• FieldRef = "Text"
• FillInChoice = "TRUE" | "FALSE"
• Filterable = "TRUE" | "FALSE"
• FilterableNoRecurrence = "TRUE" | "FALSE"
• ForcedDisplay = "Text"
• Format = "Text"
• FromBaseType = "TRUE" | "FALSE"
• Group = "Text"
• HeaderImage = "Text"
• Height = "Integer"
• Hidden = "TRUE" | "FALSE"
• HTMLEncode = "TRUE" | "FALSE"
• ID = "Text"
• IMEMode = "inactive"
• Indexed = "TRUE" | "FALSE"
• IsolateStyles = "TRUE" | "FALSE"
• JoinColName = "Text"
• JoinRowOrdinal = "Integer"
• JoinType = "INNER" | "LEFT OUTER" | "RIGHT OUTER"
• LCID = "Integer"
• List = "Text"
• Max = "Number"
• MaxLength = "Integer"
• Min = "Number"
• Mult = "TRUE" | "FALSE"
• Name = "Text"
• NegativeFormat = "MinusSign" | "Parens"
• Node = "Text"
• NoEditFormBreak = "TRUE" | "FALSE"
• NumLines = "Integer"
• Percentage = "TRUE" | "FALSE"
• PIAttribute = "Text"
• PITarget = "Text"
• PrependId = "TRUE" | "FALSE"
• Presence = "TRUE" | "FALSE"
• PrimaryKey = "TRUE" | "FALSE"
• PrimaryPIAttribute = "Text"
• PrimaryPITarget = "Text"
• ReadOnly = "TRUE" | "FALSE"
• ReadOnlyEnforced = "TRUE" | "FALSE"
• RenderXMLUsingPattern = "TRUE" | "FALSE"
• Required = "TRUE" | "FALSE"
• RestrictedMode = "TRUE" | "FALSE"
• ResultType = "Text"
• RichText = "TRUE" | "FALSE"
• RichTextMode = "Text"
• RowOrdinal = "Integer"
• Sealed = "TRUE" | "FALSE"
• SeparateLine = "TRUE" | "FALSE"
• SetAs = "Text"
• ShowAddressBookButton = "TRUE" | "FALSE"
• ShowField = "Text" | "Choice" | "Counter"
• ShowInDisplayForm = "TRUE" | "FALSE"
• ShowInEditForm = "TRUE" | "FALSE"
• ShowInFileDlg = "TRUE" | "FALSE"
• ShowInListSettings = "TRUE" | "FALSE"
• ShowInNewForm = "TRUE" | "FALSE"
• ShowInVersionHistory = "TRUE" | "FALSE"
• ShowInViewForms = "TRUE" | "FALSE"
• Sortable = "TRUE" | "FALSE"
• SourceID = "Text"
• StaticName = "Text"
• StorageTZ = "UTC" | "Abstract"
• StripWS = "TRUE" | "FALSE"
• SuppressNameDisplay = "TRUE" | "FALSE"
• TextOnly = "TRUE" | "FALSE"
• Title = "Text"
• Type = "Data_Type"
• UniqueId = "Text"
• UnlimitedLengthInDocumentLibrary = "TRUE" | "FALSE"
• URLEncode = "TRUE" | "FALSE"
• URLEncodeAsUrl = "TRUE" | "FALSE"
• UserSelectionMode = "Text"
• UserSelectionScope = "Integer"
• Viewable = "TRUE" | "FALSE"
• Width = "Integer"
• WikiLinking = "TRUE" | "FALSE"
• XName = "Text"

Links interesantes:

• http://grounding.co.za/blogs/brett/archive/2008/09/08/sharepoint-how-to-provisioning-a-site-column-with-caml.aspx
• http://msdn.microsoft.com/es-es/library/aa543203.aspx (Procedimiento para agregar una columna a un sitio: SPFieldCollection.Add y SPFieldCollection.AddFieldAsXml)
• http://sharepointmagazine.net/technical/development/customizing-the-user-experience-of-sharepoint-custom-fields-deep-dive-part-5-of-6

Hasta la próxima…

Leer más...

Master pages en SharePoint

WSS 3 fue diseñado para trabajar con páginas maestras, lo que constituye un importante cambio respecto a WSS 2, y facilita enormemente la personalización de un sitio a través de distintas páginas. En esta artículo comentaré algunos puntos importantes a tener en cuenta a la hora de trabajar con este tema en SharePoint:

Introducción

Las páginas que están vinculadas a una página maestra se denominan content pages. Estas páginas comparten un diseño común, provisto por la página maestra. La página maestra contiene placeholders que pueden ser reemplazados por contenido único.
Un importante punto a tener en cuenta es que las páginas maestras que utilizan las application pages son distintas a las que utilizan las site pages. La mayoría de las application pages trabajan con la página maestra llamada application.master, que no puede ser personalizada. Si están buscando un método que afecte a los dos tipos de páginas, les recomiendo que lean el artículo Cambios de estilos en SharePoint.
Default.master es la página estándar  utilizada por por las site pages y pueden encontrarla en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL\default.master. Cuando ustedes crean un nuevo sitio en SharePoint, se crea automáticamente la galería Master Page con una instancia de la default.master en /_catalogs/masterpage/default.master. A esta altura el lector ya habrá descubierto que las páginas maestras dentro de los sitios se comportan de la misma manera que las páginas de sitio y aplican los mismos conceptos. Por ejemplo, usted podría personalizar una página maestra desde SharePoint Designer y los cambios se almacenarían en la base de datos.
Qué podemos definir en una página maestra?

• Vínculos estándar que apliquen a todas las páginas
• Menús compartidos
• Iconos, gráficos, logos, etc.
• Componentes de navegación como el mapa del sitio
• Named Placeholders
• Delegate Controls

Named Placeholders

Como dijimos anteriormente, los named placeholders constituyen un mecanismo de extensibilidad permitiendo agregar contenido único en una página de sitio o plantilla de páhina que esté vinculada a una página maestra. El siguiente HTML es un pequeño extracto de una página maestra en SharePoint para “graficar” esta funcionalidad.

<HEAD runat="server">
<SharePoint:CssLink ID="CssLink1" runat="server"/>
<SharePoint:Theme ID="Theme1" runat="server"/>
<Title ID=onetidTitle>
      <asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/>
    </Title>
</HEAD>

CssLink y Theme existen también en application.master y ese es uno de los motivos por el cual afectan a ambos tipos de páginas, a diferencia de la personalización de la página maestra que estamos viendo en este momento.

Veamos ahora como se ve el named placeholder en una plantilla de página:

<%@ Page MasterPageFile="~masterurl/default.master" %>
<asp:Content ID="PageTitle" runat="server" ContentPlaceHolderID="PlaceHolderPageTitle"> Home de Surpoint
</asp:Content>

Controles de Navegación

Varios opciones de navegación pueden ser modificadas en las páginas maestras. Este tema está fuera del alcance de este artículo, pero a modo de ejemplo es bueno saber que puede alterarse mediante programación el funcionamiento de el menú lateral o superior en el evento de activación de una feature. Lo interesante de este punto es que mediante programación de pueden lograr resultados que no pueden alcanzarse con la funcionalidad OOTB (out of the box).

Delegate controls

Los controles delegados constituyen una potente funcionalidad de sharepoint que definen regiones dentro de las páginas maestras que pueden ser sustituidas para resolver algún requerimiento. Lo más interesante es que esto puede ser realizado sin necesidad de alterar la página maestra, ya que la operación se realiza a través de una feature. Para mayor información consultar el artículo Mi primer delegate control.

Personalizando default.master

Como dijimos anteriormente, esto es algo que puede hacerse mediante Sharepoint Designer. Si optamos por esa opción, sepamos que aplican las reglas de ghosting de las sites pages. En este artículo veremos como realizar estos cambios a través de Visual Studio. Esto abarca tres pasos:

1. Crear la plantilla de página maestra
2. Instanciarla
3. Redireccionar las páginas a nuestra nueva página maestra

Para crear la plantilla de página maestra, podemos hacer una copia de la default.master y modificarla o empezar desde cero. Recomiendo la primera.

Para instanciarla, usaremos una feature que incluya un elemento de módulo. Ejemplo:
<Module Name="MasterPages" List="116" Url="_catalogs/masterpage">
<File Url="Surpoint.master" Type="GhostableInLibrary" />
</Module>

Algunas observaciones:

• 116 identifica la galería de páginas maestras
• GhostableInLibrary significa que la página maestra se instanciará en una librería de páginas maestras

El último paso es redireccionar las páginas de sitio a la nueva página maestra. Afortunadamente esto se puede realizar en forma sencilla programáticamente en un evento de activación de feature.:

SPWeb sitio= SPContext.Current.Web;
string PathPagMaestra = sitio.ServerRelativeUrl;
if (!PathPagMaestra.EndsWith(@"/")) PathPagMaestra+= @"/";
PathPagMaestra+= @"_catalogs/masterpage/Surpoint.master";
sitio.MasterUrl = PathPagMaestra;
sitio.Update();

Algunas observaciones más:

• El ámbito de las páginas maestras es sitio (no colección de sitios).
• Ademas de MasterUrl existe CustomMasterUrl. Esto permite tener una segunda página maestra e intercambiarlas programáticamente.

Hasta aquí este artículo introductorio. Pueden encontrar información adcional en Automated SharePoint Site Branding.

Como siempre, espero que les sea útil. Hasta la próxima!

Leer más...

70-541 – Crear una Definición de Sitio

Continuando con los apuntes que fuimos armando para la certificación, veamos qué es y cómo se crea una Definición de Sitio.

Una definición de sitio define un tipo único de sitio de SharePoint. Una definición de sitio puede incluir más de una configuración de definición de sitio. ¿Qué significa esto? Que a partir de una única definición de sitio, podremos crear distintos tipos de sitios. Los sitios Web de SharePoint se basan en configuraciones de definición de sitio determinadas.

Básicamente, una definición de sitio está compuesto por los siguientes archivos:

• WebTemp.xml – Se ubica en \TEMPLATE\<LENGUAJE>\XML y en él se identifican las definiciones de sitio y proporciona información sobre cómo aparecerán sus configuraciones en la sección Selección de plantilla de la página Nuevo sitio de SharePoint. Si va a crear una definición de sitio personalizada, no edite el archivo WebTemp.xml original. En su lugar, cree un archivo personalizado denominado WebTemp*.XML. Esto simplifica la instalación y desinstalación de definiciones de sitio, ya que su contenido no necesita combinarse en un archivo WebTemp.xml.
• Onet.xml – Se ubica en \TEMPLATE\SITEDEFINITION\<TIPO DE SITIO>\XML y en él se define las áreas de exploración, especifica las definiciones de lista disponibles en la página Crear, especifica las plantillas de documento y sus archivos, define los tipos base para las listas y define las configuraciones y los módulos para las definiciones de sitio. Más adelante, en este mismo artículo explicaremos en más detalle el contenido de este archivo.
• Schema.xml – Se ubica en \TEMPLATE\FEATURES\<LISTA DEFINICION> Define las vistas, los formularios, la barra de herramientas y los campos especiales en una definición de lista. Cada definición tiene su propio archivo Schema.xml.

La definición de un nuevo sitio, se hace modificando estos tres archivos, los cuales puede hacerse copiando una definición de sitio existente y luego modificar la copia (no es recomendable modificar una definición de sitio standard) o creándolos desde cero. 

Onet.xml

A partir del archivoarchivo Onet.xml, se pueden hacer las siguientes definiciones:

• Áreas de exploración superior y lateral que aparecen en la página principal y en las vistas de lista para una definición de sitio
• Especificar las definiciones de lista que se usan en cada definición de sitio y si están disponibles para crear listas en la página Crear.
• Especificar plantillas de documento que están disponibles en la definición de sitio para crear listas de la biblioteca de documentos en la página Nuevo, y especificar los archivos que se usan en las plantillas de documento.
• Definir los tipos de listas base de los que se derivan las listas predeterminadas de Windows SharePoint Services.
• Especificar las configuraciones de las listas y módulos que se usan dentro de cada definición de sitio.
• Especificar los componentes de Windows SharePoint Services.
• Definir la sección de pie de página usada en el correo electrónico de servidor.

La estructura de este archivo va en dependencia a la definición del sitio que se crea y sus distintas configuraciones, siendo los siguientes elementos comunes a todas las definiciones:

• Elemento Project: especifica un nombre predeterminado para los sitios que se crean mediante cualquiera de las configuraciones de sitios en la definición de sitio y especifica el directorio que contiene las subcarpetas en las que residen los archivos para cada definición de lista.
• Elemento NavBars: contiene las definiciones para el área de exploración superior que se muestra en la página principal o en las vistas de lista, y las definiciones para el área de exploración lateral que se muestra en la página principal.
  • NavBar ID="1002" – Corresponde a la barra superior.
  • NavBar ID="1004" – Corresponde a la barra lateral.
• Elemento ListTemplates: especifica las definiciones de lista que forman parte de una definición de sitio.
• Cada elemento ListTemplate especifica un nombre interno que identifica la definición de lista. El elemento ListTemplate también especifica un nombre para mostrar para la definición de lista y si la opción para agregar un vínculo en la barra Inicio rápido aparece seleccionada de forma predeterminada en la página Nuevo. Además, este elemento especifica la descripción de definición de lista y la ruta de acceso a la imagen que representa la definición de lista, las cuales se muestran en la página Crear. Si se especifica Hidden="TRUE", la definición de lista no aparece como una opción en la página Crear.
• Elemento DocumentTemplates: define las plantillas de documento que se enumeran en la página Nuevo.
• Elemento Configurations: Cada elemento Configuration en la sección Configurations especifica las listas y módulos que se crean de forma predeterminada cuando se crean instancias de la configuración de definición del sitio. Para mas detalle, ver http://surpoint.blogspot.com/2009/10/70-541-especificar-la-configuracion-de.html.
• Elemento Modules: La colección Modules especifica los módulos para incluir de forma predeterminada al crear una colección de sitios. Cada elemento Module a su vez especifica uno o más archivos que se van a incluir, normalmente para los elementos web, que se almacenan en la memoria caché en el servidor cliente web, junto con los archivos de esquema. Para más detalle, ver http://surpoint.blogspot.com/2009/10/70-541-creacion-de-modulos-en-una.html.
• Elemento Components: El elemento Components especifica componentes para incluir en los sitios creados mediante la definición.
• Elemento ServerEmailFooter: El elemento ServerEmailFooter especifica la sección de pie de página usada en el correo electrónico enviado desde el servidor.

Nos vemos en la próxima entrega.

Leer más...

Crear un una plantilla de páginas con zonas de elementos web programáticamente

Breve post para explicar como crear un template de página con múltiples webparts zones e instanciarla. Los templates de páginas son los que ven cuándo elijen crear una página de elementos web desde el navegador.

Paso 1: Crear el template de página

Para crear la plantilla debemos construir una página ASPX que herede de Microsoft.SharePoint.WebPartPages.WebPartPage. Está página debe almacenarse en la carpeta \TEMPLATES\CONTROLTEMPLATES\. Un ejemplo sencillo de plantilla sería:

<asp:Content ID="main" runat="server" ContentPlaceHolderID="PlaceHolderMain" >

<table width="100%"> <tr>

<td valign="top" style="width:50%"> <WebPartPages:WebPartZone ID="LeftZone" runat="server" FrameType="TitleBarOnly" Title="Left Web Part zone" /> </td>

<td valign="top" style="width:50%"> <WebPartPages:WebPartZone ID="RightZone" runat="server" FrameType="TitleBarOnly" Title="Right Web Part zone" /> </td>

</tr> </table>

</asp:Content>

Paso 2: Instanciar la página

Por supuesto podemos instanciar la página desde el navegador. Nos aparecerá una página cómo la que se muestra en la imagen en la que podemos agregar nuestras webparts:

Existen dos maneras de hacerlo programáticamente, a través de un módulo o a través de la API de SharePoint.

a) Módulo

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<Module Path="PageTemplates" Url="SitePages" >

<File Url="PlantillaSurPoint.aspx" Name="InstanciaSurPoint.aspx" Type="Ghostable" >

<AllUsersWebPart WebPartZoneID="LeftZone" WebPartOrder="0">

<![CDATA[ <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image"> <Assembly>Microsoft.SharePoint, ...</Assembly> <TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart</TypeName> <FrameType>None</FrameType> <Title>Mi elemento web</Title> <iwp:ImageLink>https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAse6LsweeswAhy8jxIFE5sEN-jIP1IVGzj6P55_DKeDbWUTCcrhZLJE6dv2vl20SCAn07a1BeHBNk3WCqgw6vYofpLfr2tZBW7Mg8q0MX1TFnempFpCSq7o-IuNa1Ir_7lMjq4ZOHj00L/s1600-r/surpoint.png</iwp:ImageLink> </WebPart> ]]>

</AllUsersWebPart> </File>

</Module> </Elements>

b) API

SPWeb sitio = SPContext.Current.Web;           

SPFile pagina = sitio.GetFile("SitePages/InstanciaSurPoint.aspx");

SPLimitedWebPartManager Manejador;

Manejador = pagina.GetLimitedWebPartManager(PersonalizationScope.Shared);

ImageWebPart elemento = new ImageWebPart();

elemento.ChromeType = PartChromeType.None;

elemento.ImageLink = @"https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAse6LsweeswAhy8jxIFE5sEN-jIP1IVGzj6P55_DKeDbWUTCcrhZLJE6dv2vl20SCAn07a1BeHBNk3WCqgw6vYofpLfr2tZBW7Mg8q0MX1TFnempFpCSq7o-IuNa1Ir_7lMjq4ZOHj00L/s1600-r/surpoint.png";

Manejador.AddWebPart(elemento, "RightZone", 0);

Hasta la próxima…

Leer más...

70-541 Especificar la configuración de listas y módulos en una definición de sitio.

Otra de las secciones presentes en el archivo de definición de sitio Onet.xml, es la sección Configuration.

Básicamente lo que nos permite esta sección es poder reutilizar un mismo archivo de definición de sitio para poder generar distintos sitios. Sin esta sección, si tenemos dos sitios que se diferencien entre si porque uno tiene dos listas adicionales pero comparten las 10 listas restantes deberíamos armar dos definiciones de sitio uno con 10 listas y otro con 12. Con esta sección, definimos un sólo site definition e indicamos en la configuración el tipo de sitio a crear y que listas toma uno u otro.

Ahora bien, ¿qué es lo que contiene esta sección?

En el archivo Onet.xml, cada configuración de definición de sitio define un tipo específico de sitio que se puede crear a partir de la definición de sitio. Todas las configuraciones dentro de este archivo comparten un conjunto de definiciones de lista, plantillas de documento, áreas de exploración, tipos de lista base y módulos disponibles que se definen dentro del archivo.

Los principales atributos de esta sección son los siguientes:

• ID: Obligatorio – Especifica un identificador único para la configuración.
• Name: Opcional – Nombre con que se va a mostrar en la selección de plantilla.
• RootWebOnly: Opcional – Especifica si esta plantilla va a estar disponible solamente para crear sitio de primer nivel (no subsitios).
• SubWebOnly: Opcional - Especifica si esta plantilla va a estar disponible solamente para crear subsitios (no sitio de primer nivel).

Dentro de la sección Configuration, se pueden especificar las siguientes secciones (que iremos explicando en otros artículos en este mismo blog):

• ExecuteURL
• Lists
• Modules
• SiteFeatures
• WebFeatures

Hasta una próxima entrega.

Leer más...

70-541 – Creación de Módulos en una Definición de Sitios

La definición de Modules y su contenido se realiza dentro de la sección Modules del archivo de definición de sitio Onet.xml

La colección Modules especifica los módulos para incluir de forma predeterminada al crear una colección de sitios.

Cada elemento Module a su vez especifica un archivo o colección de archivos y una ubicación en la que se instalan los archivos durante la creación del sitio. Si el archivo es una página de elementos web, la definición del módulo puede especificar los elementos web que deben incluirse en la página.

Cada elemento File, especifica un archivo a aprovisionar, los principales atributos de este elemento son los siguientes:

• URL: especifica el nombre de un archivo para crear cuando se crea el sitio. Si no se especifican los atributos Name y Path, URL indica tanto el archivo físico dentro del template como el archivo virtual.
• NavBarHome: especifica si el archivo actuará o no como la página destino para el vínculo Home en la barra de navegación.
• Type: especifica si el archivo se almacena en la memoria caché del servidor y el modo de almacenamiento. Si el archivo se agrega a una biblioteca de documentos, se deberá especificar Type="GhostableInLibrary", en cambio si el archivo no se encuentra en una biblioteca de documentos se deberá colocar Type="Ghostable".

Dentro de cada elemento File, se puede especificar el elemento NavBarPage en donde se va a indicar la posición de la página respecto al área de exploración superior de una página, para que pueda ser accedida. Si lo que se quiere es que esta página aparezca en la parte superior del área de exploración, se debe especificar el atributo Position=”Start”, si quiere se que sea el último valor, se debe especificar Position=”End”, caso contrario se puede especificar un número de secuencia.

Leer más...

SharePoint en el celular - Personalizando los campos de las vistas

Este es un muy breve blog para explorar una de las características de Sharepoint en cuanto al desarrollo en la plataforma móvil. En líneas generales es importante saber que Sharepoint está prepaprado para operar dentro de un móvil agregando simplemente una "/m" a la URL.
Sí, es automático:



Una vista de tipo móvil es una vista dentro de Sharepoint que está "marcada" para poder operar en un equipo móvil. Esto puede realizarse desde la misma interfaz para personalizar una vista. Si entran a una vista verán las siguientes opciones en la sección móvil:

Estos dos atributos permiten indicar si la vista es móvil y si es la vista móvil predeterminada. Esto puede ser especificado programáticamente en el CAML del elemento view de la siguiente manera:


<View BaseViewID="1" Type="HTML" WebPartZoneID="Main" DisplayName="$Resources:core,camlid4;" DefaultView="TRUE" MobileView="True" MobileDefaultView="True" Url="AllItems.aspx">


A partir de acá ya es terreno conocido. Para elegir que campos mostrar programáticamente se trabaja de la misma manera que en vistas comunes, con el elemento View.


Les dejo algunos links para ampliar el tema:
- MSDN: Introducción al desarrollo móvil (wss)
- MSDN: Vistás móviles (wss)


Hasta la próxima...

Leer más...

Introducción a características (features) de Sharepoint – Parte 2

Este es el artículo número dos de la serie. Pueden consultar la primera parte en este link. Luego de haber analizado los usos más comunes de las features de sharepoint, vamos a ver tres temas que tienen que ver con despliegue de características:

Dependencia de features

Este es un concepto sencillo y permite que al activar una feature, se activen en forma automática las features que dependen de esta:

<Feature

Id=""
Title="Feature Activation Dependencies"
Description="Specify a feature that depends on another feature to activate"
Version="1.0.0.0"
Hidden="false"
Scope="Web"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ActivationDependencies>
<ActivationDependency
FeatureId=""/>
</ActivationDependencies>
</Feature>

Existen algunas reglas de aplicación. A modo de ejemplo no se permite la activación dependiente entre características de ámbitos (scope) distintos, las dependencias sólo pueden ser de un nivel y las características ocultas no pueden tener dependencias. Más información en MSDN: Ámbito y dependencias de activación y MSDN: Elemento ActivationDependencies.

Asociación de features (Stapling)

Esta técnica permite asociar features a definiciones de sitios. La principal ventaja radica en evitar crear una definición de sitio (tema algo complejo). Por el contrario lo que se hace es extender los sitios pre-existentes a través de features. Veamos un ejemplo:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <FeatureSiteTemplateAssociation

Id=""
TemplateName="STS#0" />
</Elements>

En el ejemplo, estamos asociando la feature a la definición de sitio STS y dentro de ese a la plantilla de sitio (o configuración) Team Site (#0). Si se desea asociar la feature en forma global, incluyendo Sharepoint Central Administrator, corresponde usar TemplateName="GLOBAL#0". Más información en MSDN: Asociación de características.

Localización de características

A través de un archivo de recursos se puede trabajar con la localización de aplicaciones para distintos lenguajes. Para ello es necesario construir un archivo de recursos, por ejemplo: Resources.en-US.resx (tener en cuenta que el lenguaje default se encuentra en resources.resx)

<root>

<resheader name="resmimetype">
<value>text/microsoft-resx</value>
</resheader>
<resheader name="version">
<value>2.0</value>
</resheader>
<resheader name="reader">
<value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<resheader name="writer">
<value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<data name="Holamundo" xml:space="preserve">
<value>Hi world</value>
</data>
</root>

Ahora, imaginemos que queremos localizar el título y descripción de una feature:

<Feature
Title="$Resources:HolaMundo"
Id=""
</Feature>

Para información más detallada consultar:

• http://www.baktek-web.com/en/topics/Localizing%20features%20with%20resources%20files.aspx
• http://blog.myitechnology.com/2009/06/localization-of-sharepoint-project.html
• http://tomblog.insomniacminds.com/2008/02/25/sharepoint-internals-resources/
  

Hasta la próxima…

Leer más...

Introducción a características (features) de Sharepoint – Parte 1

La feature es una funcionalidad de WSS 3.0 orientada al desarrollador. Permite definir elementos de sitio y agregarlos al sitio a través del proceso denominado "activación". ¿Qué tipos de elementos permite definir? Comandos de menú, plantillas de páginas, instancias de páginas, definiciones de listas, eventos, workflows entre otros.

Para crear una feature se necesita crear un archivo XML denominado "feature.xml":

Feature.xml

<Feature

Id=""
Title="Mi primera feature"
Description="Esta es la primera feature que desarrollo"
Scope="Web"
Hidden="FALSE"
ImageUrl="...gif"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>

Los atributos básicos de este XML son:

• Id: GUID de la característica. Puede ser creado con la aplicación "Create GUID".
• Scope: una característica se activa o desactiva dentro del alcance definido por el scope: Web / Site / WebApplication / Farm.
• Hidden: este atributo hará que la característica no sea visible por los usuarios y por lo tanto deberá ser activada en forma obligatoria desde la línea de comandos.
• ElementManifiest: contiene los elementos que define esta característica. Lo veremos más adelante.
  

Más información en MSDN: Trabajo con características y MSDN: Archivos Feature.xml.

Elements.xml

Veamos un ejemplo de elements.xml en el que definimos una custom action para el menú "Site Actions".

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
Id="SiteActionsToolbar"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Sequence="100"
Title="Mi primera accion"
Description="una acción de ejemplo"
ImageUrl="...gif" >
<UrlAction Url ="/_layouts/SampleUrl.aspx"/>
</CustomAction>
</Elements>

Esta característica agregará la custom action. Los atríbutos más importantes del XML son:

• Sequence: especifica la prioridad de ordenamiento.
• URLAction: la URL de la página que es llamada desde la acción personalizada.
  

Más información en MSDN: Creación de una característica simple y MSDN: Elemento CustomAction (Acción personalizada).

Instalar la característica

Para instalar una característica se deben realizar dos pasos:

• Instalación
• Activación

Esto se describe en otro artículo: surpoint: Instalando una feature en sharepoint.

Agregando un evento a una característica

Avancemos un poco más y veamos como agregar un evento a una característica, evento que se ejecutará cuando la característica de active por ejemplo.

using System;
using Microsoft.SharePoint;
namespace surpoint{
public class FeatureReceiver : SPFeatureReceiver {
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb site = SPContext.Current.Web;
site.ApplyTheme("Wheat");
site.Update();
}

Esta característica modifica el tema de SharePoint en el momento en que la característica es activada. Para que funcione correctamente, debe modificarse el archivo "feature.xml" como se indica a continuación:

<Feature

Id=""
Title="Mi primera feature"
Description="Esta es la primera feature que desarrollo"
Version="1.0.0.0"
Scope="Web"
Hidden="FALSE"
ImageUrl="...gif"
ReceiverAssembly="surpoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=..."
ReceiverClass="surpoint.FeatureReciever"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>

Es importante realizar un ISSRESET porque los ensamblados instalados en la GAC están cacheados.

Más información en:

• surpoint: Cambios de estilos en sharepoint
• surpoint: ¿Qué eventos maneja sharepoint?
• Punto de Encuentro: Registrar un Evento mediante una Feature
  

Creando un control delegado

La forma de crear una característica con un control delegado se describe en otro artículo: surpoint: Mi primer "delegate control".

Hasta aquí la parte 1. Que la disfruten y en breve la parte 2…

Leer más...