Combinaciones de lista y proyecciones

Artículo
09/24/2014

Última modificación: lunes, 02 de agosto de 2010

Hace referencia a: SharePoint Foundation 2010

En este artículo
Combinaciones y proyecciones en vistas de listas
Combinaciones y proyecciones en consultas
Combinaciones implícitas sin un elemento de combinaciones

En este tema se describe el uso de combinaciones de listas y proyecciones de campo en vistas y consultas definidas con Lenguaje de marcado de la aplicación de colaboración (CAML).

Combinaciones y proyecciones en vistas de listas

Una vista de listas puede incluir campos de otras listas que se combinaron con la lista principal. El elemento CAML View implementa esta funcionalidad mediante sus elementos secundarios Joins y ProjectedFields, que se representan en el modelo de objetos mediante las propiedades Joins y ProjectedFields del objeto SPView. (El objeto SPQuery tiene propiedades con los mismos nombres. Vea Combinaciones y proyecciones en consultas para obtener más información).

Combinaciones de listas en vistas

El elemento Joins contiene uno o más elementos Join. Cada uno de estos elementos crea una combinación interna o una combinación externa izquierda entre dos listas. Al menos una de estas combinaciones debe ser de la lista primaria de la vista, denominada lista primaria, y de alguna otra lista, denominada la lista externa. Pero puede haber combinaciones adicionales de esa lista externa a otra lista externa, y así sucesivamente. No hay límite para la cantidad de vínculos que puede haber en una cadena de combinaciones, pero la cantidad total de elementos Join, esté o no en cadenas, no puede superar el valor de la propiedad MaxQueryLookupFields para el objeto SPWebApplication que contiene la lista principal. El valor predeterminado del sistema es ocho. Una lista puede combinarse con sí misma directamente o como una cadena de combinaciones.

Importante
Al crear combinaciones de listas deben tenerse en cuenta algunos requisitos. No se pueden combinar dos listas cualquiera sin tener en cuenta el tipo. Y si dos listas pueden combinarse, no se puede usar cualquier campo principal y externo como el par de campos "join on". El campo de la lista principal debe ser un campo de tipo Lookup y debe realizar una búsqueda al campo de la lista externa. Por este motivo, todas las combinaciones reflejan las relaciones de búsqueda ya existentes entre listas.

Al crear combinaciones de listas deben tenerse en cuenta algunos requisitos. No se pueden combinar dos listas cualquiera sin tener en cuenta el tipo. Y si dos listas pueden combinarse, no se puede usar cualquier campo principal y externo como el par de campos "join on". El campo de la lista principal debe ser un campo de tipo Lookup y debe realizar una búsqueda al campo de la lista externa. Por este motivo, todas las combinaciones reflejan las relaciones de búsqueda ya existentes entre listas.

El siguiente marcado de ejemplo describe un sitio web de SharePoint Foundation que hospeda un club familiar de venta de ropa infantil entre sus miembros. Se necesita una vista de la lista Orders que muestre la ciudad y el estado del miembro que compra (customer) y la ciudad del miembro que vende (shipper). Para implementarlo, hay dos cadenas de combinaciones externas izquierdas:

Orders a Members a Cities a States
Orders a Members a Cities

Observe lo siguiente acerca del marcado Joins:

El atributo Type de cada elemento Join puede ser "LEFT" o "INNER".
Debido a que hay dos combinaciones de Orders a Members, deben distinguirse. El atributo ListAlias facilita esta distinción al asignarle a la lista Members el alias "customer" en la primera combinación pero le asigna el alias "shipper" en la segunda combinación.
También hay dos combinaciones de Members a Cities y se distinguen de la misma forma.
No hay ningún lugar donde se asigne explícitamente ningún alias de lista a una lista. La asignación no es necesaria porque cada combinación refleja una relación de campo de búsqueda existente y la definición del campo de búsqueda identifica la lista externa.
Los campos "join on" se identifican mediante un par de elementos FieldRef. El primer elemento representa el campo Lookup en la lista primaria y lo identifica mediante su nombre interno. Debe tener un atributo RefType establecido en "Id". Si la lista primaria de la combinación no es la lista primaria de la vista, entonces se identifica también con un atributo List establecido en su alias. El segundo elemento FieldRef de cada par identifica la lista externa, nuevamente por alias, y el campo de clave externa, que debe ser siempre el campo "Id".

<Joins>
  <Join Type='LEFT' ListAlias='customer'>
    <Eq>
      <FieldRef Name='CustomerName' RefType='Id'/>
      <FieldRef List='customer' Name='ID'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='customer_city'>
    <Eq>
      <FieldRef List='customer' Name='CityName' RefType='Id'/>
      <FieldRef List='customer_city' Name='Id'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='customer_city_state'>
    <Eq>
      <FieldRef List='customer_city' Name='StateName' RefType='Id'/>
      <FieldRef List='customer_city_state' Name='Id'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='shipper'>
    <Eq>
      <FieldRef Name='ShipperName' RefType='Id'/>
      <FieldRef List='shipper' Name='ID'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='shipper_city'>
    <Eq>
      <FieldRef List='shipper' Name='CityName' RefType='Id'/>
      <FieldRef List='shipper_city' Name='Id'/>
    </Eq>
  </Join>
</Joins>

Campos proyectados en vistas

El elemento ProjectedFields crea campos desde las listas externas para que puedan usarse en la vista de listas. A continuación, los campos deben identificarse en el elemento secundario ViewFields del elemento View.

Para continuar con el ejemplo del club familiar, ProjectedFields crea campos para la ciudad del cliente, el estado del cliente y la ciudad del vendedor. Observe lo siguiente acerca de este marcado:

Las listas externas se identifican mediante sus alias, según se define en el elemento Joins.
El atributo ShowField identifica qué campo de la lista externa se usa en la vista.
El atributo Type siempre tiene el valor "Lookup". Por este motivo, el atributo Type no indica el tipo de dato del campo tal como lo hace siempre en un elemento Field. Cuando un elemento Field es el elemento secundario de un ProjectedFields, Type indica simplemente si el Join (en el elemento Joins del que depende el elemento ProjectedFields) se basa en una relación de búsqueda existente entre las listas. Todas las combinaciones deben basarse en una relación de búsqueda existente. A continuación se muestra una lista de los tipos de campos en CAML que pueden ser campos proyectados.

<ProjectedFields>
  <Field 
    Name='CustomerCity'
    Type='Lookup'
    List='customer_city'
    ShowField='Title'/>
  <Field 
    Name='CustomerCityState'
    Type='Lookup'
    List='customer_city_state'
    ShowField='Title'/>
  <Field 
    Name='ShipperCity'
    Type='Lookup'
    List='shipper_city'
    ShowField='Title'/>
</ProjectedFields>

Únicamente los tipos de campo siguientes pueden incluirse en un elemento ProjectedFields:

Calculated (se trata como texto sencillo)
ContentTypeId
Counter
Currency
DateTime
Guid
Integer
Note (únicamente una línea)
Number
Text

Como se indicó anteriormente, también es necesario que los campos creados en el elemento ProjectedFields se especifiquen en el elemento ViewFields. El marcado siguiente continúa el ejemplo.

<ViewFields>
  <FieldRef Name='CustomerCity'/>
  <FieldRef Name='CustomerCityState'/>
  <FieldRef Name='ShipperCity'/>
</ViewFields>

Combinaciones y proyecciones en consultas

También se pueden usar combinaciones y campos proyectados en consultas de CAML. En este uso, las combinaciones y los campos proyectados también se definen con elementos Joins y ProjectedFields. Sin embargo, estos elementos no son elementos secundarios del elemento Query. Son marcados XML independientes que forman el valor de las propiedades SPQuery.Joins y SPQuery.ProjectedFields del objeto SPQuery que representa la consulta.

Generalmente es mejor usar el proveedor LINQ to SharePoint para consultar listas de SharePoint Foundation con código de servidor. Debido a que CAML tiene los elementos Joins y ProjectedFields, el proveedor LINQ to SharePoint, que traduce consultas de LINQ a consultas de CAML, puede admitir completamente los operadores de LINQ join (Join en Visual Basic) y select (Select en Visual Basic). Si el código está diseñado para ejecutarse en clientes, se recomienda consultar mediante Consultas a SharePoint Foundation con los servicios de datos de ADO.NET.

Si desea crear consultas de CAML directamente y establecer las propiedades pertinentes de un objeto SPQuery de manera explícita, debe considerar el uso de una herramienta para generar las consultas. Para encontrar tales herramientas, navegue a www.bing.com y busque "CAML query tool" sin comillas. Es posible que transcurra un tiempo después del lanzamiento de Microsoft SharePoint Foundation 2010 hasta que haya disponibles herramientas que admitan la generación de elementos Joins y ProjectedFields.

En el ejemplo siguiente se muestra una consulta que devuelve todos los pedidos de una lista Orders en los que la ciudad del cliente es Londres. En este ejemplo se asume que la lista Orders tiene un campo CustomerName que busca una lista Customers y que esta última lista tiene un campo CityName que busca una lista Cities.

La consulta requiere una combinación de Orders a Customers y de Customers a Cities, por lo tanto el valor de la propiedad Joins sería el siguiente.

<Joins>
  <Join Type=’LEFT’ ListAlias=’customers’>
    <Eq>
      <FieldRef Name=’CustomerName’ RefType=’Id’ />
      <FieldRef List=’customers’ Name=’ID’ />
    </Eq>
  </Join>

  <Join Type=’LEFT’ ListAlias=’customerCities’>
    <Eq>
      <FieldRef List=’customers’ Name=’CityName’ RefType=’Id’ />
      <FieldRef List=’customerCities’ Name=’ID’ />
    </Eq>
  </Join>
</Joins>

Debido a que la sección Dónde de la consulta probará la ciudad del cliente, debemos crear un campo CustomerCity. Por lo tanto, el valor de ProjectedFields es el siguiente.

<ProjectedFields>
  <Field
    Name=’CustomerCity’
    Type=’Lookup’
    List=’customerCities’
    ShowField=’Title’ />
</ProjectedFields>

A continuación, debemos hacer que el campo esté disponible. Para eso, agregamos una referencia al campo en el elemento ViewFields. Por lo tanto, el valor de la propiedad ViewFields es el siguiente.

<ViewFields>
  <FieldRef Name='CustomerCity'/>
</ViewFields>

Finalmente, la propiedad Query se establece de la siguiente forma.

<Query>
  <Where>
    <Eq>
      <FieldRef Name='CustomerCity'/>
      <Value Type='Text'>London</Value>
    </Eq>
  </Where>
</Query>

Combinaciones implícitas sin un elemento de combinaciones

Se recomienda usar un elemento Joins explícito cuando la consulta de CAML implique una combinación de listas, a fin de maximizar la legibilidad de su marcado. Al hacerlo, también aumentará la posibilidad de que el marcado de la consulta sea compatible con versiones futuras de SharePoint Foundation. Sin embargo, hay una manera de admitir una combinación implícita de dos listas sin usar un elemento Joins. Puede crear simplemente un elemento ProjectedFields tal como se describe arriba, excepto que el elemento secundario Field tiene un atributo FieldRef en lugar del atributo List. FieldRef tan solo identifica la columna Lookup en la lista de origen. Además, cuando el elemento ProjectedFields tiene un atributo FieldRef en lugar de un atributo List, se le debe dar a su atributo Name un valor arbitrario que no sea el mismo que cualquier columna de la lista de origen. (De nuevo, en este marcado no es necesario identificar la lista de objetivo porque se especifica en la configuración de la relación Lookup).

Por ejemplo, suponga que con las mismas listas y relaciones de búsqueda de la sección anterior tiene la siguiente consulta y el siguiente elemento ViewFields.

<Query>
  <Where>
    <Eq>
      <FieldRef Name='CustomerName'/>
      <Value Type='Text'>Hicks, Cassie</Value>
    </Eq>
  </Where>
</Query>

<ViewFields>
  <FieldRef Name='CustomerName'/>
</ViewFields>

Observe que el elemento Where realiza una combinación implícita entre las listas Orders y Customers. Se puede admitir esta consulta con únicamente el siguiente elemento ProjectedFields. No sería necesario un elemento Joins. (Tenga en cuenta que al atributo Name se le dio un nombre arbitrario distinto del nombre de columna de búsqueda especificado con el atributo FieldRef).

<ProjectedFields>
  <Field
    Name=’OrderingCustomer’
    Type=’Lookup’
    FieldRef=’CustomerName’
    ShowField=’Title’ />
</ProjectedFields>

Aún con esta técnica, sigue siendo un requisito que haya una relación de búsqueda entre la columna de origen y la lista de destino. Además, con esta técnica no es posible encadenar combinaciones. Por ejemplo, no se puede admitir el elemento Query que se muestra al final de la sección anterior. Esa consulta hace una combinación doble implícita de Orders a Customers a Cities. Una cadena de combinaciones requiere un elemento Joins explícito.

Vea también

Otros recursos

Administración de datos con LINQ to SharePoint

Compartir a través de