Procedimiento para crear un tipo de campo personalizado

Artículo
09/24/2014

Última modificación: jueves, 03 de marzo de 2011

Hace referencia a: SharePoint Foundation 2010

En este artículo
1. Creación de una definición de tipo de campo
2. Creación de una clase de campo
3. Creación de una hoja de estilos XSLT personalizada (opcional)
4. Creación de una clase de control de representación
5. Creación de una o más plantillas de representación
6. Creación de un tipo de valor de campo (opcional)
7. Creación de un control de edición (opcional)
8. Implementación de los elementos
Diferencias entre la representación de campos para dispositivos móviles y la representación de campos para equipos

En este tema se proporciona información general sobre el proceso mediante el que se crea un tipo de campo personalizado y se define del modo en que éste se representa en las vistas de lista y en los formularios de presentación, creación y edición.

Para obtener un ejemplo concreto de la creación de un campo personalizado y la definición de su representación, vea Tutorial: Crear un tipo de campo personalizado.

1. Creación de una definición de tipo de campo

Una definición de tipo de campo es un archivo XML que contiene la información que Microsoft SharePoint Foundation necesita para registrar el tipo de campo y representar el campo correctamente. Lo más importante es que contiene información sobre el ensamblado que incluye el tipo de campo compilado.

Para obtener más información sobre las definiciones de tipo de campo, vea Procedimiento para crear una definición de tipo de campo personalizado.

2. Creación de una clase de campo

Una clase de campo es una clase cuyas instancias pueden representar campos específicos que se basan en el tipo de campo personalizado. Esta clase debe proceder de SPField o de una de las clases de SharePoint Foundation que derivan de éste. La clase se compila en un ensamblado con nombre seguro y se implementa en la memoria caché global de ensamblados. En el contexto de una vista de lista, un objeto SPField representa una columna y sus propiedades (por ejemplo, si puede ordenarse o no). En el contexto de los modos de presentación, creación y edición, un objeto SPField representa un campo específico de un elemento de lista (una celda de la tabla que constituye la lista) y el valor de esa celda en la base de datos de contenido.

Si lo desea, esta clase puede contener validación de datos personalizada para el tipo de campo. Para obtener más información acerca de la validación personalizada, vea Validación de datos de campos personalizados.

Para obtener más información sobre las clases de campos personalizados, vea Procedimiento para crear una clase de campos personalizados.

3. Creación de una hoja de estilos XSLT personalizada (opcional)

La forma habitual en la que SharePoint Foundation representa los campos en una vista de lista es a través de hojas de estilos XSLT. De forma predeterminada, las hojas de estilos integradas de SharePoint Foundation simplemente representan el valor del campo en texto sin formato. Si desea realizar representaciones en las vistas de lista de otra manera, el sistema debe tener un ingrediente básico para representar el campo personalizado, que es una hoja de estilos XSLT personalizada. Se denomina con el patrón fldtypes_*.xsl y se implementa en %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATES\LAYOUTS\XSL. La hoja de estilos personalizada tiene prioridad sobre la hoja de estilos predeterminada.

El encabezado de la parte superior de una columna en las vistas de lista también se representa a través de una hoja de estilos XSLT y, de nuevo, debe crear una nueva hoja de estilos para invalidar la que está integrada, solo en el caso de que sea necesario que el encabezado de columna para el tipo de campo personalizado no se represente de manera estándar.

Para obtener más información acerca de cómo crear una hoja de estilos XSLT para el campo personalizado, vea Procedimiento para personalizar la representación de un campo en una vista de lista.

Nota

Si tiene un tipo de campo personalizado heredado desarrollado en una versión anterior de SharePoint Foundation y éste se representaba en las vistas de lista de forma diferente al modo de representación predeterminado proporcionado por la infraestructura de representación XSLT, tiene la opción de desactivar la representación XSLT del campo. Para ello, agregue <Field Name="CAMLRendering">TRUE</Field> como un elemento secundario del elemento FieldType en el archivo fldtypes*.xml que contiene la definición de Lenguaje de marcado de la aplicación de colaboración (CAML) del campo personalizado heredado. El uso de esta opción hace que el campo (y el encabezado de columna) de las vistas de lista se represente de acuerdo con RenderPattern. Para obtener más información, vea Elemento RenderPattern (Tipos de campo).

4. Creación de una clase de control de representación

Una clase de control de representación se usa junto con una plantilla de representación (vea la siguiente sección) para representar los campos en los modos de creación, edición o presentación. Esta clase debe proceder de BaseFieldControl o de una de las clases de SharePoint Foundation que derivan de éste. Esta clase se compila en el mismo ensamblado que la clase de campo.

La lógica de validación se implementa mediante los miembros Validate, IsValid y ErrorMessage del control de representación de campos y mediante el método GetValidatedString del tipo de campo subyacente. (CreateChildControls puede llamar a Validate.)

Para obtener más información acerca de los controles de representación, vea Procedimiento para crear un control de representación de campos.

5. Creación de una o más plantillas de representación

Cada control de representación de campos tiene al menos una plantilla de representación de campos asociada para representar un campo en los modos de creación, edición o presentación. Esta asociación se realiza haciendo que el control de representación de campos tenga, en una de sus propiedades, una referencia al identificador de la plantilla de representación de campos. En tiempo de representación,SharePoint Foundation busca la plantilla necesaria realizando una búsqueda de los identificadores de todas las plantillas de representación declaradas en archivos .ascx en %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES (todos ellos se cargan al iniciar la aplicación web). Con frecuencia, el método CreateChildControls del control de representación realiza una última optimización de la representación del campo, pero la mayoría del trabajo de representación se realiza mediante la plantilla. El método CreateChildControls es el que suele asignar valores predeterminados a los controles secundarios del control de representación en el modo de creación, mientras que en los modos de edición y presentación asigna los valores actuales del campo a los controles secundarios. También puede llevar a cabo otras tareas de optimización de la representación, como asignar una clase CSS a un control Label secundario.

Por lo general, debe tener dos plantillas de representación: una para representar el campo en un formulario editable en los modos de creación y edición, y otra para representarlo en un formulario de solo lectura en el modo de presentación. Sin embargo, es posible que los tres modos compartan la misma plantilla de representación o tener una plantilla de representación distinta para cada modo. Puede incluso tener varias plantillas para un modo determinado, con lógica que invoque a una u otra según los aspectos del contexto, como el contexto de usuario específico o el tipo de lista o sitio en que aparece el campo.

Para obtener más información acerca de las plantillas de representación, vea Procedimiento para crear plantillas de representación de campos.

Una plantilla de representación para los modos de creación y edición suele requerir controles interactivos (y así, cuadros de texto editables, casillas, botones de radio y controles de lista desplegable) como controles secundarios. No obstante, normalmente el modo de presentación requiere únicamente controles Label or Literal u otros controles de presentación estática. Por esta razón, es probable que deba crear una plantilla de representación diferente para el modo de presentación. Puede especificar esta plantilla (mediante un identificador) en la propiedad DisplayTemplateName. La plantilla principal que se va a usar fuera del modo de presentación se especifica mediante la propiedad TemplateName().

La plantilla de representación que realmente se usa para representar el campo en cualquier contexto es la que devuelve la propiedad ControlTemplate del control de representación. El descriptor de acceso get de dicha propiedad selecciona una de las plantillas de representación asociadas con el control de representación mediante criterios de decisión como los siguientes:

El contexto HTTP actual
El modo de control
Si el campo es obligatorio
Si el campo, en caso de ser numérico, debe representarse en forma de porcentaje
Si el elemento de lista es una carpeta o no

Puede invalidar esta propiedad y hacer que el descriptor de acceso get compruebe el modo de control y devuelva DisplayTemplate cuando se use el modo de presentación (si no se ha establecido de forma explícita en alguna otra plantilla, DisplayTemplate devuelve la plantilla identificada por DisplayTemplateName). A menos que necesite una lógica de decisión diferente en el descriptor de acceso get para ControlTemplate, puede hacer que llame al descriptor de acceso get de la propiedad base en el modo de creación o edición.

Nota

Un medio alternativo de designar una plantilla de representación en modo de presentación consiste en que el método CreateChildControls asigne DisplayTemplateName a TemplateName en el modo de presentación (a menos que se haya invalidado, ControlTemplate devuelve Template y, a menos que el descriptor de acceso get de éste último esté invalidado, devuelve la plantilla identificada por TemplateName). Un posible inconveniente de usar el método CreateChildControls es que éste no se ejecuta en un contexto en el que el campo no se representa, como cuando, por ejemplo, en las depuraciones se comprueba el valor de ControlTemplate en el modelo de objetos.

6. Creación de un tipo de valor de campo (opcional)

Si va a crear una clase de campo personalizada que requiere una estructura de datos especial para los datos de campo, puede crear una clase de valor (o estructura) para que contenga los datos de campo.

Para obtener más información acerca de cómo crear clases de valores personalizadas, vea Procedimiento para crear una clase de valores de campo personalizados.

7. Creación de un control de edición (opcional)

Si bien todos los tipos de campo requieren un nombre, un tipo de datos, una descripción y otras propiedades comunes, muchos de ellos también tienen propiedades que están relacionadas únicamente con los campos de ese tipo específico. Son los usuarios quienes establecen estas propiedades de variable en la interfaz de usuario (UI) cuando crean una nueva columna basada en el tipo de campo en cuestión. Normalmente, un elemento en la definición de tipo de campo (vea más arriba en este tema) determina cómo se representan estos controles de configuración de propiedades. Sin embargo, a veces se necesita un control de edición especial. Este control se define en el control de usuario; es decir, un archivo .ascx que normalmente tiene un archivo de código subyacente que contiene su lógica. Se recomienda crear un control de edición especial si es necesario realizar funciones personalizadas, como lógica de cálculo compleja, búsqueda de valores de los orígenes de datos o validación de datos personalizados de los valores que un usuario puede haber elegido cuando configuró una nueva columna.

Nota

Los controles de edición para las propiedades de variable no deben confundirse con los archivos .ascx de plantilla de representación descritos anteriormente. La plantilla de la representación representa un campo y su valor en una página para crear, editar o presentar un determinado elemento de una lista existente, que normalmente ya tiene definidas sus columnas. El control de edición para propiedades de variable, por el contrario, representa ciertas propiedades del tipo de campo cuando se crea una columna en función de ese tipo.

Para obtener más información acerca de la representación del tipo de campo personalizado y los controles de edición para las propiedades de variable, vea Representación de propiedades de tipo de campo personalizado y Controles del editor para propiedades de tipo de campo.

8. Implementación de los elementos

Para obtener más información acerca de dónde implementar las distintas clases y archivos que ha creado, vea Implementación de tipos de campo personalizados.

Diferencias entre la representación de campos para dispositivos móviles y la representación de campos para equipos

En SharePoint Foundation, la representación de campos con controles de representación de campos personalizados para dispositivos móviles es similar a la representación de campos con controles de representación de campos personalizados para equipos. No obstante, tenga en cuenta las siguientes diferencias:

Las páginas móviles son un conjunto totalmente diferente de páginas con respecto a las páginas normales y hacen referencia a un conjunto diferente de plantillas RenderingTemplate.
Las plantillas RenderingTemplate móviles se declaran en MobileDefaultTemplates.ascx, no en DefaultTemplates.ascx.
Los controles de representación de campos móviles tienen su propio espacio de nombres, Microsoft.SharePoint.MobileControls (en lugar de Microsoft.SharePoint.WebControls), y proceden de clases de System.Web.UI.MobileControls de ASP.NET en lugar de System.Web.UI.WebControls.
La jerarquía de herencia de los controles de representación de campos móviles es algo diferente de la de los controles de representación de campos habituales. Por ejemplo, las funciones de TemplateBasedControl y FormComponent en la representación de campos habitual se combinan en la clase SPMobileComponent.
Los controles de representación de campos personalizados que cree para contextos móviles se basan más en el método CreateChildControls del control para representar un campo y, en consecuencia, menos en la plantilla de representación (en la que se basan los controles de representación de campos personalizados que se crean para exploradores de equipos). Además, en los controles de representación móviles personalizados el método CreateChildControls en sí no se suele invalidar. En su lugar, se suelen invalidar uno o varios de los otros cuatro métodos a los que se llama mediante CreateChildControls:
Para obtener más información acerca de la representación de páginas móviles y los controles de representación de campos personalizados, vea Sistema de representación de páginas móviles y Tutorial: creación de un control de representación de campos personalizado para páginas móviles.