Uso de content types y features en WSS v3

Tratando de seguir el testigo de los excelentes artículos de Carlos Segura sobre la nueva funcionalidad de content types en SharePoint Services v3, vamos a intentar explicar un ejemplo concreto de su uso, que el propio producto utiliza en las Team Discussions, y con ello ver el mecanismo de empaquetado de soluciones de las features.

La implementación de grupos de discusión en SharePoint es muy sencilla, existe una plantilla de librería que se puede instanciar en un sitio, ofreciendo la funcionalidad de crear posts y respuestas, con dos tipos de vista, plana o jerarquizada.

 

Como con cualquier lista de SharePoint, es posible activar la aprobación de nuevos posts (no se ven hasta que un administrador los aprueba) o el versionado (para hacer seguimiento de quién los ha modificado). En caso de activar estas funciones, podemos controlar quién ve los posts que están en estado ‘draft’ (si tenemos versionado y estamos trabajando en ellos) o ‘pending’ (si hemos activado la aprobación de contenidos y estamos esperando a que un administrador los apruebe).

 

Al entrar dentro de uno de los threads, se muestran los mensajes asociados en función de una vista de SharePoint.

De forma plana:

 

O jerarquizada:

 

Veamos la estructura de información que da soporte a esta lista. Los diseñadores de SharePoint han activado la capacidad de almacenar diferentes content types. De esta forma, la lista es una especie de almacén de objetos estructurados, cada uno de ellos con sus propios campos. Adicionalmente, la lista puede añadir columnas a las aportadas por los content types, de forma que lo almacenado finalmente es la unión de las columnas diferentes de todos los content types y las restantes que defina la lista.

 

El content type Discussion deriva de Folder (una carpeta para organizar elementos en una lista), que a su vez desciende de Item, el elemento básico de una lista. Discussion añade a folder un campo body (el contenido del post) y un campo de email.

 

Message hace algo parecido, desciende de Item y le añade los campos de body y email.

 

El funcionamiento es sencillo (ya veremos como no lo es tanto), en el primer nivel se crean elementos de tipo discussion, y por debajo de ellos elementos message. Hay una vista predeterminada que nos muestra los elementos de tipo discussion de primer nivel, y al entrar en uno de estos elementos, hay disponibles dos vistas adicionales, la plana (todos los elementos por debajo de esta discussion) y la threaded, que muestra las relaciones entre mensajes. Estas vistas están desarrolladas con formularios de presentación personalizados.

Evidentemente, con los campos que se muestran a través de la web, es imposible hacer todo esto. Faltan las relaciones entre posts para crear las jerarquías, los campos calculados como Replies, que cuenta los posts que hay por debajo de un folder… Toda esta lógica está implementada en una feature (el elemento para empaquetar cualquier tipo de solución en SharePoint 2007), que se encuentra activa por defecto en WSS.

Para ver cómo funciona, es necesario ir a la definición de la feature, que se puede encontrar en la carpeta Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEFEATURES, en este caso en la carpeta DiscussionList.

Dentro de la feature DiscussionsList se encuentra el fichero schema.xml que contiene la definición completa de la lista, sus ContentTypes, campos, vistas, formularios personalizados, que implementan las funcionalidades de la lista.

Los dos content types tienen bastantes más campos, que al tener una propiedad hidden, no se muestran en la vista Web. La definición completa se puede encontrar en el fichero ctypectypeswss.xlm, de la carpeta FEATURES. en la imagen de abajo podemos verlos en una versión modificada de la página aspx que muestra las propiedades.

 

Cuando comparamos los campos que se ven en la vista web y los de los tipos de contenidos, vemos que no aparecen algunos campos que luego si aparecen en las diferentes vistas. Por ejemplo el campo calculado ‘Replies’, que contiene el número de ítems por debajo de una carpeta. Vamos a seguir los pasos que SharePoint da para definir un campo como este.

La etiqueta ‘Replies’ se toma del fichero general de recursos multi-idioma, en el caso de nuestra instalación ‘core.en-US.resx’ que se encuentra en el directorio Program FilesCommon FilesMicrosoft Sharedweb server extensions12Resources. A la etiqueta ‘Replies’ le corresponde un nombre de campo ‘Reply_Count’.

 

Con la identificación del campo, buscamos en el fichero schema.xml de nuestra lista dónde se referencia, y observamos que es el campo con el nombre ‘ItemChildCount’ dentro del parámetro DisplayName="$Resources:core,Reply_Count;"

Su definición completa es esta:

<Field ID="{b824e17e-a1b3-426e-aecf-f0184d900485}"
 Name="ItemChildCount"
 SourceID=http://schemas.microsoft.com/sharepoint/v3
 StaticName="ItemChildCount"
 Group="_Hidden"
 ReadOnly="TRUE"
 Filterable="FALSE"
 Hidden="FALSE"
 DisplayName="$Resources:core,Reply_Count;"
 Type="Lookup"
 List="Docs"
 FieldRef="ID"
 ShowField="ItemChildCount"
 JoinColName="DoclibRowId"
 JoinRowOrdinal="0"
 JoinType="INNER">
</Field>

El campo es de tipo Lookup (una búsqueda dinámica sobre una lista), en este caso aplicada a la propia lista Docs. Muestra como resultado el campo ItemChildCount, una propiedad de SPBuiltInFieldId. La información del SDK no recoge todavía la información detallada sobre estos campos. Los joins permiten generar lookups uniendo las listas de origen y destino (en este caso, son la misma). El resultado es que podemos contabilizar los ítems que cuelgan por debajo de un folder, que en este caso corresponde a las respuestas por debajo de un post.

Esperamos que con la publicación de la Beta2TR se complete la documentación para conocer el funcionamiento detallado de las nuevas características y se arreglen los problemillas que tiene por ahora este excelente producto.

Problemas con la optimización TCPIP en Windows Vista

Hola,

Si estáis probando las betas de Windows Vista, es posible que os encontréis con problemas con las comunicaciones, páginas que se empiezan a abrir pero no terminan de descargar. Parace que tiene que ver con la incorrecta implementación en algunos routers domésticos de optimizaciones de tamaños de ventanas y retransmisiones del protocolo TCP/IP, que Vista activa por defecto.

Para beta 2 Microsoft publicó un parche, y en la RC1 debería estar resuelto, pero al menos con nuestro router, un Linksys RV082, sigue fallando, tanto para conexiones salientes como entrantes. La inspección de paquetes SPI del firewall descarta paquetes y las comunicaciones se bloquean, salvo que se desactive el FW.

Si os pasa, se pueden deshabilitar las optimizaciones automáticas de Vista desde un cmd, con esta línea:

   netsh interface tcp set global autotuninglevel=disabled

Como netsh está controlado por UAC, no permite el cambio directamente, es preciso hacerlo como administrator, para ello, crear un acceso directo a un cmd, botón derecho, "run as administrator".

Saludos,

Saludos desde Cantabria

Hola,

Os escribimos desde el Centro de Innovación en Integración de Cantabria, un proyecto creado por el Gobierno de Cantabria y Microsoft para ayudar a las empresas TIC regionales a acceder a las últimas tecnologías y que puedan ser más competitivas.

Estamos trabajando sobre SharePoint 2007, WCF, WWF y Biztalk, y esperamos poder contar cosas en una comunidad tan interesante y experta como esta.

Gracias a los administradores de Geeks y a la gente de Plain Concepts por la oportunidad de participar.

Saludos,