Jul29

[MOSS] Introducción a las features

Tags: MOSS/WSS

 

  1.  ¿Qué es una feature?

Una feature o característica es una conjunto de archivos XML que encapsulan una funcionalidad propia de SharePoint, simplificándolo un poco puede decirse que una feature es un fichero de XML de configuración de dicha funcionalidad que SharePoint reconoce como tal y que permite que mediante el interfaz de la propia aplicación web los usuarios puedan activar o desactivar esa feature y la funcionalidad asociada a ella.

2. ¿Qué clase de Funcionalidad puede implementar una feature?

- Añadir un nuevo elemento en un menú de SharePoint con nueva funcionalidad

- Crear elementos de SharePoint: columnas de sitio, tipos de contenido (content types), lista, sitios, webparts
- Desplegar paginas maestras, layouts, imágenes, plantillas (.stp),....

- Instanciar event handler, timer jobs, workflows.
......

3. ¿De qué ficheros se compone una feature?


Una feature se define con un fichero Feature.xml que es el principal fichero de definición y en el que se detalla desde un guid que identifica a la feature, el titulo, el ámbito (scope), la descripción o los elementos de los que se compone, por otra parte además una feature puede contener un archivo normalmente elements.xml (o cualquier otra denominación) donde se defina la funcionalidad u otros archivos que forman parte de la feature. Normalmente las features se estructuran en estos dos archivos, aunque puede ser que toda la información se encuentre en el feature.xml solamente.

3.1. Atributos del fichero Feature.xml

· Id (*): guid, identificador único de la feature

· Scope (*): ámbito de acción la feature, puede ser Farm, WebApplication, Site o Web.

Es importante tener en cuenta este parámetro a la hora de definir una feature ya que en gran medida dependerá de la funcionalidad de la feature. Digamos que es el nivel al que la feature será activada.

· Title: titulo de la feature

· Description: descripción de la feature

· ImageUrl: url de la imagen asociada a la feature

· ReceiverAssembly:nombre completo del ensamblado que contiene la clase Custom Feature Event Receiver, este atributo siempre lleva asociado el uso del atributo ReceiverClass

· ReceiverClass: nombre de la clase que implementa el Custom Feature Event Receiver.

· ActivationDependencies: este atributo se usa cuando se necesita que para la activación de una feature previamente otra este activada, y si no es así no permitirá la activación.

(*)->OBLIGATORIOS

Estos son solo los atributos más destacados, aquí se puede encontrar una guía completa.

3.2. Elements.xml

Es un fichero opcional si bien es bastante común (la funcionalidad que ofrece puede integrarse dentro del fichero feature.xml, aquí se explican las posibles ventajas). Si nos fijamos en el fichero feature.xml siguiente se observa que contiene un enlace al elements.xml:

<ElementManifest Location="elements.xml" />

Sirve tanto para definir otros archivos de los que se compone nuestra feature: plantillas (.stp), webparts, controles,… como para definir la acción que se llevará a cabo por la feature en sí, en el ejemplo siguiente se muestra un fichero elements.xml que define la acción que realizará la siguiente feature:

3.3. Feature de ejemplo

Este ejemplo define una feature bastante básica que insertará una nueva opción en el menú de acciones de SharePoint y al pulsar sobre el mostrará un mensaje de tipo alert.

Este el Feature.xml:

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

<Feature Id="1B4C3AD8-4213-400c-84BE-C5AFE7C64333"

Title="Feature de prueba"

Description="Descripción de la feature de prueba"

Version="1.0.0.0"

Scope="Site"

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

<ElementManifests>

<ElementManifest Location="elements.xml" />

</ElementManifests>

</Feature>

Elements.xml

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

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

<CustomAction Id="FeatureDePrueba"

GroupId="SiteActions"

Location="Microsoft.SharePoint.StandardMenu"

Sequence="1010"

Title="Feature de prueba"

Description="Descripción de la Feature de prueba "

ImageUrl="/_layouts/images/ewr033.gif">

<UrlAction Url="javascript:void alert('Feature de prueba');"/>

</CustomAction>

</Elements>

3.4. Uso de la feaure

La feature que acabamos de definir mediante estos dos ficheros es perfectamente usable, para comprobarlo solo necesitamos crear una nueva carpeta dentro de la ruta destinada a las features de SharePoint donde se instalan los binarios de SharePoint, normalmente: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Template\Features

Esta ruta creamos una nueva carpeta en este caso FeaturePrueba y dentro introducimos los ficheros anteriores: feature.xml y elements.xml

clip_image001[7]

Ahora solo faltará instalar dicha feature para que SharePoint la reconozca como tal, para esto usamos el comando de stsadm installfeature (el ejecutable de stsadm en la instalación por defecto de SharePoint se encuentra en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Bin):

stsadm –o installfeature –name FeaturePrueba

En este punto hay que destacar que el parámetro que se introduce para el atributo “name” es el mismo que el nombre de la carpeta contenedora de la feature que se va a instalar.

clip_image003

Y acto seguido estará disponible para ser activada desde Administrar características de la colección de Sitios (hay que recordar que el ámbito en este caso era Site, por lo tanto se activará para toda la colección de sitios)
clip_image004[4]

Una vez la activamos, la opción que definíamos estará disponible en el menú de acciones:

clip_image005

Y al pulsar sobre ella, mostrará un mensaje de tipo Alert:

clip_image006[4]

Publicado: 29-Jul-09 | 0 Comentarios | 0 Enlaces a este post

Jul01

[MOSS]Asociar un event receiver a un ContentType

Tags: MOSS/WSS

 

Los event receivers son una opción muy interesante que dan mucho juego a la hora de desarrollar soluciones de SharePoint.

Básicamente son eventos que se pueden asociar a elementos de listas o documentos de bibliotecas de documentos, tareas de listados de tareas,a sitios… en el momento de creación , borrado, modificación….

El objeto que implementa esta funcionalidad es SPEventReceiver del que heredaremos a la hora de declarar la clase que determine dicha funcionalidad.

Para definir la funcionalidad de un event receiver normalmente lo desarrollaremos integrado dentro de una feature, y en el fichero feature.xml vincularemos el código a ejecutar como assembly de la nueva feature.

En la mayoría de las situaciones que se me habían presentado era suficiente con declarar un event receiver asociado a una lista, ya que la problemática que solucionaba estaba circunscrita a dicha lista.

Actualmente me encuentro desarrollando un portal con variaciones y hay múltiples listas de diferentes sitios que debería vincular con el event receiver, tras investigar un rato averigüé que no solamente puede asociarse un event receiver a una lista, elemento o sitio, sino que también puede asociarse a un content type. Independiente de donde esté almacenado la lógica se ejecutará sin tener en cuenta el sitio o lista contenedor, por lo tanto para mi esta era la solución correcta.

Para esto en la feature que despliega este tipo de contenido hay que añadirle un nodo de tipo XmlDocuments, donde definiremos el evento de cada uno de los elementos que asociaremos, pro ejemplo en el siguiente caso el evento se ejecutará cada vez que se añada un nuevo elemento de este tipo de contenido o que se modifique:

 

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType ID="CONTENT TYPE ID" Name="CONTENT TYPE NAME" Group="Custom" Description="CONTENT TYPE DESCRIPTION" Version="0">
    <FieldRefs>
      <FieldRef ID="FIELD ID" Name="FIELD NAME" />
    </FieldRefs>
   <XmlDocuments>
      <XmlDocument NamespaceURI="
http://schemas.microsoft.com/sharepoint/events">
        <spe:Receivers xmlns:spe="
http://schemas.microsoft.com/sharepoint/events">
          <Receiver>
            <Name>Event Receiver Item added</Name>
            <Type>ItemAdded</Type>
            <SequenceNumber>10000</SequenceNumber>
Assembly>Prueba, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0a26195ff03df1fd</Assembly>
            <Class>Prueba.EventRec</Class>
            <Data></Data>
            <Filter></Filter>
          </Receiver>
          <Receiver>
            <Name> Event Receiver Item updated </Name>
            <Type>ItemUpdated</Type>
            <SequenceNumber>10000</SequenceNumber>
            <Assembly>Prueba, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0a26195ff03df1fd</Assembly>
            <Class>Prueba.EventRec</Class>
            <Data></Data>
            <Filter></Filter>
          </Receiver>
        </spe:Receivers>
      </XmlDocument>
    </XmlDocuments>
  </ContentType>
</Elements>

Y el código que se ejecutaría asociado a cada una de las acciones:

namespace Prueba

{

public class EventRec:SPItemEventReceiver

{

public override void ItemUpdated(SPItemEventProperties properties)

{

base.ItemUpdated(properties);

///Codigo a ejecutar posterior evento update……

}

public override void ItemAdded(SPItemEventProperties properties)

{

base.ItemUpdated(properties);

///Codigo a ejecutar posterior evento add……

}

}}

Publicado: 01-Jul-09 | 1 Comentario | 1 Enlace a este post