Despliegues con Powershell

Hola

Estoy empezando a probar Powershell como herramienta para hacer despliegues (fundamentalmente para despliegues incrementales). De momento tiene buena pinta. Quiero compartir aquí un artículo que he encontrado donde explica que Powershell tiene algún problema para gestionar correctamente la destrucción de los objetos en memoria, en concreto los objetos SPSite y SPWeb. En este artículo (http://blogs.msdn.com/sharepoint/archive/2009/02/11/sharepoint-and-powershell-knowledge.aspx) explican cómo escribir un script de Powershell que tenga en cuenta este problema.

Un saludo!!!!!!!

Content Deployment

Hola a todos!!

Este es mi primer artículo en el blog, y en el vamos a estudiar una de las nuevas características de Microsoft Office Sharepoint Server 2007 (MOSS 2007 en adelante), que seguro utilizaremos en más de uno de nuestros proyectos para realizar los tan temidos despliegues a producción. Veamos de que se trata y como realizar un despliegue.

¿Qué es Content Deployment?

Se trata de una de las últimas y más importantes características de la nueva versión MOSS 2007. Content Deployment no es más que copiar, parcial o totalmente, contenido de un sitio origen a un sitio destino. Se puede copiar un sitio completo o parte de él, o inclusive copiar sólo el contenido que ha cambiado. En definitiva, usaremos Content Deployment para migrar el contenido de una colección de sitios que hacen la función de entorno de desarrollo o edición a otra colección de sitios de producción, donde los usuarios visualizan finalmente el contenido.

Las experiencias de migración de contenido con versiones anteriores de Sharepoint desde luego que resultaban tediosas. En la nueva versión MOSS 2007 este trabajo resulta mucho más fácil e intuitivo. Si pensamos un momento como diseñaríamos nuestro propio despliegue de contenidos, seguro que llegaríamos a una solución extremadamente parecida a la que nos proporciona esta nueva versión de Sharepoint. Partiendo de dos entornos implementados con éxito, el primero haciendo la labor de edición de contenidos y el último la labor de producción, pensemos que pasos deberíamos dar a continuación para llevar los contenidos de un servidor a otro. Parece lógico pensar que tendremos que definir en alguna parte la ruta o dirección del despliegue, y eso casi todos podríamos pensar que debe estar en el servidor de origen, al igual que cuando un avión despega de un aeropuerto establece en el ordenador de abordo los parámetros de la ruta a seguir para llegar a su destino. En el servidor de destino de los contenidos lo único que parece necesario definir es la posibilidad de entrada de los mismos, es decir, dar un permiso especial para que los contenidos puedan entrar en la base de datos, como haría la torre de control de ese aeropuerto destino con el avión que despegó del origen. Este concepto de ruta de contenidos se denomina Path en Sharepoint, y sirve para establecer los parámetros de dirección del servidor origen y destino además proporcionar la cuenta con derechos de acceso en el servidor destino.

Teniendo definida la ruta para los contenidos, finalmente nos preguntaremos cuando debe realizarse, es decir, necesitamos algo para poder parametrizar la hora de despegue de nuestro avión. Para ello tendremos lo que en MOSS 2007 se denomina Job, que permitirá establecer ciertos parámetros acerca de la frecuencia o del momento exacto en el que debe ejecutarse una tarea de publicación siguiendo la ruta definida para ella.

Requisitos en origen y destino para realizar un despliegue de contenidos

Antes de realizar un despliegue de contenidos es importante tener en cuenta los siguientes requisitos previos para no obtener errores en la operación:

1. Será necesario habilitar la opción de publicación de sitio de MOSS 2007 (Office Sharepoint Server Publishing). Para ello, en la colección de sitios ir a “Site Actions > Site Settings > Modify All Site Settings > Site Features”, y comprobar que la característica se encuentra activada:

Figura 1 Office Sharepoint Server Publishing.

2. Las colecciones de sitio o sitios que se vayan a migrar en el despliegue deben estar creadas en el mismo idioma tanto en el servidor origen como en el servidor destino. Si no, se obtendrá un error como el siguiente:

Figura 2 Error de despliegue cuando las colecciones de sitio no se encuentran en el mismo idioma.

Es posible crear sitios en varios idiomas sin modificar el lenguaje de la instalación original de MOSS 2007 a través de los “Language Pack”. Se puede encontrar más información en la siguiente dirección http://www.microsoft.com/downloads/details.aspx?FamilyID=2447426b-8689-4768-bff0-cbb511599a45&displaylang=en

3. La colección de sitios del servidor de destino debe estar creada en base a la plantilla de publicación de “Sitio en blanco” o “Blank Site”:

Figura 3 Plantilla Sitio en Blanco.

Esto es debido a que si la colección se sitios de destino se crea con otra plantilla por ejemplo, la de “Collaboration Portal” numerosos objetos, como las listas por ejemplo, serán creados por defecto en la base de datos, y al realizar el despliegue e intentar volver a crearlos, se provocará un error como el siguiente:

Figura 4 Error de despliegue cuando el sitio destino no está basado en la plantilla de sitio en blanco.

4. Un paso crítico al realizar el despliegue es realizar la operación con las credenciales de una cuenta que tenga derechos de acceso en la Administración Central del servidor de destino. Esto es porque Content Deployment trabaja desde las administraciones centrales de ambos servidores. Así, si la cuenta con la que se ejecuta la operación tiene estos privilegios, podremos acceder a la información de la colecciones de sitio del destino, desde el servidor origen. En caso contrario obtendremos un error como el siguiente:

Figura 5 Error si la cuenta proporcionada no tiene privilegios de acceso a la Adm.Central.

Seguridad del despliegue de contenidos

En muchos escenarios de publicación de contenido, como se mencionó anteriormente, es muy posible (y se recomienda) que tanto el servidor fuente como el servidor destino se encuentren funcionando en distintos dominios de Directorio Activo, y sin existir una relación de confianza entre los mismos. Para dar soporte a los distintos escenarios de funcionamiento integrado de MOSS 2007 con Directorio Activo, las tareas de publicación también pueden copiar información sobre cuentas de usuario y roles desde el servidor origen al destino. Se presentan tres alternativas:

• All, al seleccionar esta opción se copiará toda la información de seguridad de roles, usuarios y ACLs, del servidor origen al destino. En este caso ambos servidores estarán funcionando en el mismo dominio para que pueda existir consistencia en la información intercambiada.
• Role definitions only, en este caso solo se copiará información relativa a roles de usuario y ACLs.
• None, con esta opción no se copiará información alguna del servidor origen al destino y todo el control de acceso, definición de roles y ACLs quedará a cargo de un administrador. Esto permite asegurar que la seguridad de ambos servidores se administre y maneje por separado.

Despliegue de contenidos paso a paso

Definir una ruta

Teniendo en cuenta que se cumplen los requisitos previos en ambos servidores, estos son los pasos para realizar un despliegue de contenidos entre dos entornos que supondremos finalmente configurados:

1. El primer paso es configurar el servidor de destino para aceptar tareas de publicación. Para ello, en el servidor de destino ir a “Central Administration > Operations > Content Deployment > Content Deployment Settings” y marcaremos la opción “Accept Incoming Content Deployment Jobs”:

Figura 6 Content Deployment Settings.

Desde esta Administración Central del servidor de destino podemos configurar otras opciones:

• Establecer el servidor que administra la importación y exportación de datos a la granja.
• Requerir el encriptado de los datos que se transportan vía HTTPs. Para las pruebas de este documento se prescindirá de esta opción.
• Establecer la ruta donde se generan los ficheros temporales durante el despliegue de contenidos. Es importante hacer notar que estos ficheros son borrados una vez finalizada la operación.
• Establecer el número de informes que se generarán en cada uno de los trabajos (Jobs) del despliegue.

2. El siguiente paso será crear la ruta para los contenidos. Para ello, en el servidor de origen ir a “Central Administration > Operations > Content Deployment > Content Deployment Paths and Jobs”. A continuación pulsaremos en “New Path”. Elegir un nombre para esta ruta, seleccionar una de las “Web Application” del servidor y la ruta donde se encuentra el “Site Collection” fuente de los contenidos:

Figura 7 Create Content Deployment Path.

3. A continuación introducir la url de la Administración Central del servidor de destino y establecer las credenciales de acceso a la misma. Podemos configurar si la conexión se realiza a través de autenticación integrada de Windows, o Básica y si es a través de la cuenta configurada para el “pool” de Sharepoint o de otra. En cualquier caso debe tener privilegios de acceso a la Administración Central del servidor de destino:

Figura 8 Authentication method and credentials.

4. Pulsar el botón de conexión. Si las credenciales son válidas, se mostrará en el desplegable el conjunto de aplicaciones web disponibles en el destino. Seleccionaremos la “Web Application” y seguidamente la url del “Site Collection” que queremos sea el destino de los contenidos, y que debe estar basada en la plantilla “Blank Site”, como vimos en el apartado anterior:

Figura 9 Destination web application.

5. Finalmente podemos definir si en la tarea de publicación se transportarán también el nombre de los usuarios de la colección de sitios de origen.

Finalizada la creación de la ruta, podemos observar como en la Administración Central se ha generado una tarea de publicación rápida de manera automática (“Quick Deploy”) para nuestra ruta:

Figura 10 Quick deploy.

En sitios web empresariales puede existir contenido que cambia constantemente y es tan crítico que necesita ser publicado cuanto antes para que sea visualizado por sus socios, empleados, gerentes, entre otros. Para estos casos se pueden configurar estas tareas de publicación rápida que se ejecutan por defecto cada 15 minutos y publican todas las páginas que hayan sido marcadas para publicación tras haberse ejecutado la última tarea. Bien, pues el problema viene ahora y es que esta tarea rápida o “Quick Deploy” no es válida para el primer despliegue de contenidos sobre una granja o servidor de producción. Si en el destino no se ha ejecutado todavía ninguna tarea de publicación y procedemos a ejecutar esta tarea rápida, veremos el éxito de la operación pero sin embargo comprobaremos que no se ha movido ningún contenido al destino. Seguramente nuestra frustración hará que volvamos a ejecutar de nuevo la tarea, y nos devolverá un error como este:

Figura 11 Error en la tarea de publicación rápida.

El sitio destino quedará inservible para sucesivas tareas de publicación y debemos borrar la aplicación web correspondiente. Sólo queda empezar de nuevo, y no cometer el mismo error. La solución para nuestro primer despliegue en producción será obviar ese “Quick Deploy”, y crear nuestra propia tarea de publicación, como veremos en el siguiente apartado. ¿Se trata tal vez de un “Bug”…?

Definir una tarea

Estos son los pasos para definir una tarea de publicación:

1. En el servidor de origen ir a “Central Administration > Operations > Content Deployment > Content Deployment Paths and Jobs”. A continuación pulsaremos en “New Job”.
2. Dar un nombre a la tarea de publicación.
3. Seleccionar la ruta anteriormente creada.
4. Seleccionar si se copiará la colección de sitios al completo, o si se prefiere, se seleccionar los sitios de la colección que se copiarán.
5. A continuación se decide la frecuencia de la publicación de contenidos hacia el servidor de destino. Podremos seleccionar una fecha y hora en concreto o establecer el intervalo de publicación cada cierto tiempo. También podemos no seleccionar ninguna frecuencia, y arrancar manualmente la tarea.

Figura 12 Frecuencia de la tarea.

6. El siguiente paso será seleccionar si el despliegue se realizará con todo el contenido de la colección o sitios seleccionados o si sólo se moverá el contenido nuevo o modificado desde la última tarea. Es importante hacer notar que si se trata de la primera tarea de publicación sobre el servidor de destino, en cualquier caso se moverá todo el contenido de la colección o sitios seleccionados en el servidor de destino. Una vez que hayamos ejecutado esta tarea por primera vez, si hemos seleccionado la opción de desplegar sólo el contenido que haya sido modificado, en sucesivas ejecuciones de esta misma tarea sólo se moverá ese contenido y no todo.
7. Finalmente podemos establecer una dirección de correo electrónico donde enviar un informe con el resultado de la operación.

Ejecutar una tarea

Una vez aceptamos la tarea ya tenemos todo listo para el despliegue. Si preparamos la tarea para realizar la publicación a una hora en concreto, pues toca esperar. Para la primera prueba, mejor podríamos ejecutar la tarea “al vuelo” haciendo uso de la opción “Run Now”, y es que apetece hacerlo cuanto antes:

Figura 13 Ejecutar una tarea.

La tarea se está ejecutando, y si todo va bien… voila, veremos un mensaje de éxito. Y si vamos al servidor de destino y refrescamos, el sitio en blanco se ha convertido en una perfecta replica de nuestro sitio de origen, a falta de pequeños detalles que tendremos que perfilar. Desde este momento, el servidor de destino queda perfectamente “enganchado” a la tarea de publicación para recibir sólo el contenido que ha variado en el origen, fantástico!

Cómo cambiar la salida HTML de un Web Part Zone

Muy buenas a todos!!!

En este artículo vamos a ver un tema muy interesante que afecta fundamentalmente a cuestiones de accesibilidad. Se trata de modificar la salida HTML del control Web Part Zone para evitar que se pinte como una tabla.

Para situarnos en el problema supongamos que tenemos un Web Part que lo único que hace es escribir, en su método Render, algo tan simple como "Web Part de Prueba". Teniendo esto en cuenta, tras arrastrar el Web Part al Web Part Zone al que queremos agregarlo, el HTML que se genera tendrá una specto similar al siguiente:

Como puede verse, el Web Part se pinta como una capa (div), y el envoltorio de tablas que lo rodea es el HTML generado por el Web Part Zone en el que se encuentra alojado el Web Part. Esta tabla supone un serio problema si queremos que nuestro sitio web cumpla las normas de accesibilidad, y si queremos, en cualquier caso, tener un HTML semánticamente correcto. La solución para cambiar la salida del Web Part Zone es muy sencilla: basta con crear un Control Adapter, que será el responsable de rescribir el nuevo HTML. Para ello, creamos en Visual Studio 2005 un nuevo proyecto de tipo Biblioteca de Clases con una clase WebPartZoneControlAdapter que herede de System.Web.UI.WebControls.Adapters.WebControlAdapter. A continuación, sobreescribiremos los métodos RenderBeginTag y RenderEndTag de la clase base sin implementación alguna, de la siguiente manera:

Estos métodos se encargan de escribir la tabla que enmarca todo el Web Part Zone (la primera de las tablas del HTML). Por tanto, no realizamos ninguna implementación de ellos y, de esta forma, no escriben nada.

El siguiente paso es sobreescribir el método RenderContents de la clase base, de la siguiente forma:

En este método, lo primero que hacemos es llamar al método RenderContents de la clase base, pasándole como parámetro el objeto HtmlTextWriter (hWriter) que hemos declarado a nivel de clase, para almacenar la salida HTML que devolvería la clase base. Como se ve en el constructor de nuestro Control Adapter, este objeto escribe el HTML resultante de la clase base en el objeto StringWriter sWriter. Capturado el texto devuelto por la clase base, lo siguiente es eliminar todo rastro de tablas, lo cual puede hacerse fácilmente mediante una expresión regular, cuyo resultado se escribe en la última línea del codigo.

Nuestro Control Adapter está listo para ser utilizado. Tan sólo un par de pasos más. El primero de ellos es desplegarlo en nuestro sitio de MOSS. Para ello, copiamos el fichero WebPartZoneControlAdapter.cs (o Class1.cs si no le has cambiado el nombre) y lo pegamos en la carpeta App_Code que tenemos que crear en el directorio de nuestro sitio web. Este directorio está en :\Inetpub\wwwroot\wss\VirtualDirectories\, si no has renombrado la carpeta con el número de puerto a otro nombre.

Una vez copiado el fichero, vamos a la carpeta App_Browsers y editamos el fichero compat.browser. Este fichero contiene la definición de los navegadores compatibles con nuestra aplicaicón Web (podéis ver más información en Browser Definition File Schema). Añadimos la siguiente información al fichero, bajo el nodo raíz browsers:

Ya tenemos todo listo para probar!!! Si vamos a nuestra página y vemos el código fuente, el resultado es el que se ve en la siguiente figura:

El resultado es el que efectivamente perseguíamos, sin embargo, hay que tener en cuenta un último detalle: cuando pasamos a modo edición aparecen numerosos errores de javascript y hemos perdido la interfaz y numerosa funcionalidad.

Lo que realmente queremos es modificar la salida HTML del Web Part Zone únicamente cuando vemos la página, no cuando la editamos. De hecho, cuando editamos una página sería deseable que apareciera con la funcionalidad habitual de MOSS. Para conseguir esto utilizaremos Reflection para acceder a las propiedades del control para el cual estamos creando el Control Adapter y poder manipular la asignación del adaptador. Esto lo haremos en el método OnLoad de nuestra clase, de la siguiente manera:

Lo que hacemos en este método es eliminar la referencia a cualquier Control Adapter que esté utilizando el control cuando la página que estamos editando esté desprotegida.

De esta forma, el Web Part Zone se pintará en modo edición tal como lo pinta WSS, pero en modo publicación utilizará nuestro adaptador y se pintará sin tablas.

Aquí tenéis todo el código para que resulte más claro:

Salvar sitio como plantilla: ¿Dónde está?

Al igual que en la versión anterior de SharePoint, una de las funcionalidades con que cuenta la nueva plataforma es la posibilidad de salvar un sitio como plantilla. Esta opción está disponible en la configuración del sitio, bajo el grupo Look and Feel.

Sin embargo, no en todos los sitios está disponible esta opción: ¿despiste? ¿Olvido? Parece que debe ser un descuido ;-)

Pero bueno, el problema se queda ahí. Si nos fijamos en la Url de la página utilizada para salvar un sitio como plantilla, vemos que se trata de una página de aplicación. Una página de aplicación, o _layout page, es una página alojada en el directorio <unidad>:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS. Este directorio "virtualiza" las páginas que incluye de modo que pueden ser invocadas desde cualquier sitio. Por ejemplo, la página para crear una nueva página, CreatePage.aspx, alojada en dicho directorio, puede ser invocada desde cualquier sitio con tan sólo añadir su ubicación a la url de ese sitio, del siguiente modo:

http://servidor/_layouts/CreatePage.aspx

http://servidor/sitio1/_layouts/CreatePage.aspx

http://servidor/sites/sitio1/_layouts/CreatePage.aspx

Pues bien, la página utilizada para guardar un sitio como plantilla se llama savetmpl.aspx, y está también alojada ("virtualizada") en el directorio LAYOUTS. Así que, en el caso de aquellos sitios donde no aparece la opción para salvar un sitio como plantilla, podemos solventar el problema agregando a la url del sitio la ubicación virtual de la página y a correr, _layouts/ savetmpl.aspx:

http://servidor/_layouts/ savetmpl.aspx

http://servidor/sitio1/_layouts/ savetmpl.aspx

Creación de definiciones de lista a partir de una lista en MOSS 2007

La creación de una nueva definición de lista en MOSS 2007 puede realizarse de varias maneras. Aquí veremos cómo crear una nueva definición a partir de una lista ya existente con la ayuda de una nueva herramienta, SharePoint Solution Generator, incluida en las Extensiones de Windows SharePoint Services 3.0 para Visual Studio 2005.

Como ejemplo crearemos una definición de lista que contenga los campos necesarios para guardar información acerca de automóviles en una intranet de una empresa de seguros.

Tipo de contenido

La lista que crearemos será de tipo Custom List. Por defecto, una lista de este tipo admite contenidos de tipo Item. Lo que haremos, por tanto, será crear un tipo de contenido específico que defina los metadatos de los elementos que debe contener nuestra lista. Esto nos permitirá, posteriormente, modificar los campos de la definición de nuestra lista mediante CAML.

Así, pues, creamos un tipo de contenido llamado Automovil. Como este tipo de contenido lo utilizaremos en una lista de tipo Custom List, seleccionaremos como Parent Content Type de nuestro tipo el grupo List Content Types y, dentro de los tipos de contenido de este grupo, el tipo Item. De esta forma, cada vez que creemos un nuevo Automovil crearemos un ítem de lista.

Entre las columnas del tipo creado figura la columna Título. Esto es así porque nuestro tipo de contenido hereda del tipo Item, el cual tiene definidas como columnas la columna Título.

A continuación, creamos las siguientes columnas para nuestro tipo Automovil:

• Marca: Single Line of Text
• Modelo: Single Line of Text
• Puertas: Number (mínimo 3, máximo 5, sin decimales)
• Combustible: Choice (Diesel/Gasolina, Drop-Down Menu)
• Nuevo: Yes/No
• Fecha Matricula: Date (Date only)
• Matricula: Single Line of Text

Creación de la lista

Una vez creado el tipo de contenido, creamos una lista de tipo Custom List, que podemos llamar Lista Automoviles. Una vez creada, tenemos que configurarla para que utilice el tipo de contenido que hemos creado en el paso anterior. Para ello, accedemos a la configuración avanzada de lista y en la sección Content Types, seleccionamos la opción Yes en Allow management of content types?.

De vuelta a la configuración de la lista, en la sección Content Types pulsamos sobre la opción Add from existing site content types, para agregar el contenido que hemos creado en el paso anterior.

En la página para agregar tipos de contenido, seleccionamos el grupo Custom Content Types y de la lista de tipos de contenido disponible seleccionamos Automovil. Una vez seleccionado, pulsamos el botón Ok para volver a la configuración de la lista.

Podemos observar cómo en la lista de columnas de la lista aparecen ahora las columnas correspondientes al tipo Automovil. Además, si accedemos a la lista para ver los elementos y desplegamos el menú New, veremos cómo aparece también como opción crear un elemento nuevo de tipo Automovil.

Como nuestra lista es para guardar datos de automóviles, no necesitamos el tipo de contenido Item, por lo que vamos a ocultarlo como tipo disponible en la lista. Para ello, accedemos de nuevo a la configuración de la lista y en la sección Content Types seleccionamos Change new button order and default content type (cuando creemos la definición de lista, veremos que no se mantienen estos cambios, pero lo hacemos ahora para ver cómo conseguir luego el mismo efecto desde CAML). En la página que se muestra a continuación, desmarcamos el campo Visible para el tipo de contenido Item. De esta manera, prevenimos que puedan crearse elementos en la lista de automóviles que no sean del tipo Automovil.

Ahora, cuando creemos un nuevo elemento en la lista, sólo estará disponible crear un elemento de tipo Automovil.

Creación de la definición de la lista con SharePoint Solution Generator

Llegados a este punto, podemos crear la definición de lista a partir de la lista que acabamos de crear mediante la nueva utilidad SharePoint Solution Generator. Al arrancar esta herramienta, se nos da la opción de crear una definición de sitio o una definición de lista. Seleccionamos crear una definición de lista y pulsamos Next.

En la siguiente pantalla que se muestra seleccionamos el sitio en el que hemos creado la lista. En nuestro caso la hemos creado a nivel del Top Level Site y pulsamos Next.

En la lista de listas que aparece a continuación, seleccionamos la lista que hemos creado: Lista Automoviles y pulsamos Next.

En la siguiente pantalla, introducimos el nombre que queremos dar a la definición de la lista, seleccionamos la ubicación en la que se guardarán los archivos y pulsamos Next para generar la solución.

La solución generada con SharePoint Solution Generator incluye un fichero con el esquema Xml de la lista (schema.xml) y cuatro plantillas ASPX para dar soporte a la lista:

• AllItems.aspx: muestra la vista por defecto con todos los elementos de la lista
• DispForm.aspx: para ver las propiedades de un elemento de la lista
• EditForm.aspx: para editar las propiedades de un elemento de la lista
• NewForm.aspx: para crear un nuevo elemento

Modificación de la definición de la lista

Por defecto, el esquema que encontramos en el fichero schema.xml contiene muchos elementos que para nuestro caso no son necesarios, así que realizaremos una serie de cambios.

Modificación de los tipos de contenido

Lo primero que haremos será modificar los tipos de contenido. Fijémonos en la sección ContentTypes:

En esta sección se definen los tipos de contenido utilizados por la lista. Vemos que se establecen dos tipos de contenido: Automovil e Item. Como se recordará, este último lo ocultamos en la configuración de la lista. Sin embargo, vemos que en la definición de la lista este tipo no está oculto. Esto significa que cuando instalemos la definición de la lista será posible crear elementos de este tipo. Esto no era deseable, ya que sólo queríamos crear elementos de tipo Automovil. En este caso, podemos optar bien por ocultar el tipo de contenido agregando el atributo Hidden al nodo ContentType del tipo Item, dándole como valor TRUE (en mayúsuclas); o bien por eliminar el nodo relativo al tipo Item. Como sólo queremos crear automóviles, optamos, por tanto, por esta última opción.

Por lo que se refiere al tipo Automovil, vemos que entre sus propiedades encontramos una que deriva del tipo del que hereda, Title. Esta columna me resulta, en muchas ocasiones, incómoda, dado que en muchas listas no tiene sentido una columna Title y renombrarla implica dificultades posteriores si queremos acceder a ella desde la API de WSS 3.0. Sin embargo, no hay manera de eliminarla desde la configuración de una lista. Afortunadamente, al construir la definición de la lista podemos eliminar el nodo relativo al campo Title para que no aparezca en las listas que creemos a partir de nuestra definición. Así, pues, eliminamos la referencia a esa columna borrando la línea en cuestión:

Modificación de los campos de la vista AllItems

Al crear la definición de la lista se crean dos vistas, una de las cuales es la vista AllItems que se muestra cuando consultamos los elementos de una lista. En la definición de esta vista, el nodo ViewFields determina los campos a los que se aplica la vista. En nuestro caso, este nodo contiene la siguiente información:

Como se ve, estos campos no tienen mucha utilidad en nuestro caso. Por ello, vamos a eliminarlos y agregaremos los campos correspondientes a nuestro tipo de contenido, de la siguiente forma:

Para terminar, modificaremos el campo por el cual se ordena la vista, el cual viene definido en la siguiente sección:

En nuestro caso, ordenaremos, por ejemplo, por el campo Marca, por lo que modificaremos el Xml de la siguiente forma:

Instalación de la lista

Una vez realizados los cambios en el esquema de la lista, lo último que nos queda es instalar la definición. Desde Visual Studio 2005 esta operación es muy sencilla. Basta con pulsar con el botón derecho del ratón sobre la solución y en el menú desplegable pulsar la opción Deploy.

Finalizado el despliegue ya podemos crear listas en base a la definición que hemos creado. El nuevo tipo de lista aparece en la sección Custom Lists.