XsltListViewWebPart y vistas de lista personalizadas
Última modificación: jueves, 21 de octubre de 2010
Hace referencia a: SharePoint Foundation 2010
La nueva clase XsltListViewWebPart de Microsoft SharePoint Foundation 2010 deriva de la clase DataFormWebPart basada en XLS. Reemplaza la clase ListViewWebPart como tipo de vista predeterminado en las vistas de lista, aunque genera HTML equivalente para la misma configuración de vista. De forma similar, la clase XsltListFormWebPart reemplaza la clase ListFormWebPart como tipo de vista predeterminado en los formularios de elementos de lista. A diferencia de la clase ListViewWebPart, la clase XsltListViewWebPart usa transformaciones XSLT para definir la representación de HTML, en vez de usar los elementos de representación de HTML del esquema de vista en el lenguaje de marcado de la aplicación de colaboración (CAML). Los archivos XSLT que se aplican a través de la clase XsltListViewWebPart se almacenan en caché en cada servidor front-end web y admiten todos los idiomas, en vez de un solo idioma por archivo XSLT. Esto proporciona mayor escalabilidad en SharePoint Foundation, ya que cada archivo XSLT se compila y consume una pequeña cantidad de recursos del servidor. Además, la clase XsltListViewWebPart usa ASP.NET AJAX para realizar el filtrado ad-hoc en vez del enfoque de IFrame que se usa en CAML, y la salida de las transformaciones XSLT que se aplican a través de la clase XsltListViewWebPart es XHTML. Ya sea que estén en vistas de lista o en formularios de elementos, la clase XsltListViewWebPart y las plantillas XSLT proporcionan la mejor forma de cumplir con los requisitos de ASP.NET AJAX, XHTML y datos externos para vistas de SharePoint Foundation y, al mismo tiempo, convergen en una sola tecnología de vista personalizable.
Puede personalizar las vistas en el explorador a través de la interfaz de usuario de SharePoint Foundation, en Microsoft SharePoint Designer 2010, o en Microsoft Visual Studio 2010. Puede implementar XSLT personalizado en la clase XsltListViewWebPart para definir vistas de lista personalizadas. El XSLT personalizado puede invalidar solo algunas plantillas en los archivos XSLT predeterminados, o bien invalidarlas todas. Puede implementar los archivos XSLT personalizados en la carpeta %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES, o en la carpeta %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS. Puede especificar vistas de lista basadas en XSLT en la sección <Views> del archivo Schema.xml para una definición de lista usando el elemento XslLink en una definición de vista. Para obtener información sobre cómo SharePoint Foundation usa plantillas de XSLT y sobre los archivos de XSLT predeterminados que se instalan, vea Información general del sistema de representación de vistas de listas XSLT.
XsltListViewWebPart genera una vista HTML de una lista a partir de datos XML obtenidos al ejecutar una consulta definida en el elemento Query de la propiedad XmlDefinition del elemento web. Además de la consulta, la propiedad XmlDefinition contiene descripciones de varios atributos de vista, como qué estilo de vista subyacente usar (por ejemplo, Basic Table o Boxed), qué campos mostrar en la vista, el número de filas de datos que se muestra en una sola página y otras configuraciones especificadas en el archivo Schema.xml de la lista. La definición de lista del archivo Schema.xml sirve como árbol de nodo de origen para el procesador XSLT, que analiza el esquema para crear el árbol de resultados que está contenido en la propiedad XmlDefinition.
La sintaxis de la propiedad XmlDefinition se basa en la propiedad SharePoint FoundationListViewXml de la clase ListViewWebPart. La clase XsltListViewWebPart usa la descripción de la consulta de la propiedad XmlDefinition para crear un control SPDataSource y recupera datos como XML. A continuación, el elemento web ejecuta una transformación XSLT en los datos XML, usando parámetros que incluyen el esquema de lista y la descripción de la vista XmlDefinition. El XSLT es independiente del esquema, lo que significa que se adapta al esquema de la lista a la que se hace referencia. Se pueden agregar o quitar campos, o cambiar su tipo, y el XSLT seguirá representando la vista correctamente. La transformación XSLT se adapta a la configuración de la vista que se especifica en la propiedad XmlDefinition, por ejemplo, para el estilo de vista. Usa <xsl:apply-templates> para iterar sobre cada fila de datos y cada campo de vista de la forma definida por el estilo de vista y el esquema de lista. Las plantillas XSLT compatibles generan salida HTML, que a continuación se envía al explorador. Para obtener información sobre cómo se usa dsQueryResponse XML en vistas de lista de XSLT para representar datos XML, vea Ejemplos de árboles de nodos de resultados y de entrada en transformaciones XSLT.
Cuando se usa la interfaz de usuario de SharePoint Foundation para modificar una vista en el explorador, cambia la configuración declarativa de la propiedad XmlDefinition del elemento web dentro de su zona de elementos web. Esto hace que el elemento web genere HTML que es equivalente a la clase SharePoint FoundationListViewWebPart. Puede personalizar aún más el elemento web en SharePoint Designer, ya que no requiere un paso de conversión y no impide que se realicen cambios adicionales en el explorador. La transformación XSLT del elemento web permanece sin cambios y almacenada en caché en una ubicación de solo lectura en el servidor front-end web y todos los controles de XsltListViewWebPart la reutilizan. Los cambios realizados en SharePoint Designer invalidan el XSLT en caché y se escriben en la propiedad Xsl del elemento web. SharePoint Foundation aprovecha las reglas de precedencia de importación y el comportamiento de compatibilidad de plantilla en XSLT para invalidar solo las plantillas especificadas. Esto permite realizar cambios de personalización específicos en el HTML que se genera, sin que ello afecte a los archivos XSLT front-end y sin copiar los cambios en el elemento web. Solo las plantillas invalidadas se guardan en la propiedad Xsl del elemento web.
Derivación de XsltListViewWebPart
La clase XsltListViewWebPart hereda de la clase DataFormWebPart según la siguiente jerarquía:
Propiedades heredadas
La clase XsltListViewWebPart hereda muchos miembros de la clase DataFormWebPart, incluidos los miembros enumerados en la siguiente tabla. La tabla indica si el equivalente XML de cada propiedad persiste como elemento o atributo.
Nombre de propiedad |
Persistencia XML |
Descripción |
|---|---|---|
Elemento |
Opcional. Especifica un objeto DataSourceCollection que representa interfaces de IDataSource. Normalmente, se usa en su lugar la propiedad XmlDefinition para sintetizar un control de origen de datos (SPDataSource) cuando se representa la vista. Se genera una excepción si esta propiedad está presente en XsltListViewWebPart. |
|
Atributo |
Contiene una referencia a una lista que usa el nombre para mostrar localizado, como Announcements. |
|
Atributo |
Contiene una referencia a una lista en formato {GUID} con la misma sintaxis que el atributo ListViewWebPart equivalente. |
|
Atributo |
Contiene una referencia a una lista en formato URL relativa al sitio web, comoLists/Announcements. |
|
Elemento |
Contiene un elemento View válido que tiene la misma sintaxis que admite la clase SharePoint FoundationListViewWebPart, menos las etiquetas de representación CAML (vea Esquema View de CAML y XMLDefinition). |
|
Atributo |
Especifica una referencia de dirección URL a un archivo XML que define el contenido de la propiedad XmlDefinition. |
|
Elemento |
Opcional. Contiene una hoja de estilo en línea. |
|
Elemento |
Opcional. Contiene una dirección URL que especifica un archivo XSLT para usar para la transformación. |
Una de las propiedades List* (ListName, ListUrl, o ListDisplayName) debe estar presente y especificar una referencia a una lista válida. Si hay presentes varias propiedades, el orden de la evaluación es ListName, después ListUrl y, a continuación, ListDisplayName.
Si una de las propiedades XmlDefinition* (XmlDefinition o XmlDefinitionLink) está presente, debe resultar en un elemento View válido. De lo contrario, se usa en su lugar la definición de vista de la vista predeterminada de la lista (es decir, de Schema.xml). Si hay más de una propiedad, el orden de evaluación es XmlDefinitionLink y, a continuación, XmlDefinition.
Al igual que con la propiedad Xsl y la propiedad XslLink de la clase DataFormWebPart, el orden de la evaluación es primero XslLink y después XSL. Si no se especifican ni XSL ni XslLink, se usa el archivo XSLT al que hace referencia el elemento View en Schema.xml para la transformación. La presencia de una propiedad XSL o XslLink indica que la vista se personalizó en SharePoint Designer para invalidar el XSLT almacenado en caché y no personalizado predeterminado. La propiedad XSL nunca se modifica a través de la interfaz de usuario de SharePoint Foundation sino solo a través de SharePoint Designer cuando se toman acciones de formato explícitas (en vez de la modificación de la consulta). Por ejemplo, el formato condicional en SharePoint Designer requiere que se actualice el contenido de XSL, pero no requiere agregar o quitar columnas.
El método GetDataSource() de la clase XsltListViewWebPart invalida el método GetDataSource() de la clase DataFormWebPart. La clase XsltListViewWebPart primero resuelve la referencia a la lista y después crea un control de origen de datos (SPDataSource) basado en el contenido de la propiedad XmlDefinition.
Vea también
Conceptos
Información general del sistema de representación de vistas de listas XSLT
Ejemplos de árboles de nodos de resultados y de entrada en transformaciones XSLT
Esquema View de CAML y XMLDefinition
Procedimiento para personalizar la representación de un campo en una vista de lista
Procedimiento para implementar recursos en vistas de lista personalizadas