Home > SharePoint > Digging in MOSS 2007 CQWP

Digging in MOSS 2007 CQWP

2012/04/20

With the Content Query Web Part you can show data from other sources , for example from a list in another site collection.

By default you can use only the common Content Types fields , so if you need to read the Title column of another site collection and display these data in a webpart there are no particular problems, but if you want to display , filter, sort, download the file clicking on the name or access to the item editing by clicking the link in CQWP ,using specific fields, on the other List / Doc library … there are many tricks to know.

For example we have a site collection with a “Discovering” Web where we have a “Corporate Identity” document library, under this we have a “BA” (Business & Applications) Web:


Above screenshot come from SharePoint Manager 2007.

The first step in the default.aspx of BA Web is to place a CQWP, after entering in edit page mode (Site Actions->Edit Page)


And select the list in above Web as default content, clicking on “Show items from the following list”:


In this “Corporate Identity” Document library we have 2 fields that in our example are “BA” and “Typology”


that we don’t see in the list for the filtering or ordering:


How to make available for filtering , grouping and sorting the specific fields of our Document Library ?

We must set our CQWP the most possible similar (set some fake filtering and ordering, limit the items, title and so on) to our desired final result then export the CQWP, from the export menu:


In this manner is exported a .webpart file that contains all definitions, in practice an XML file that contains a series of <property> nodes.

In our case we need some additional fields for display and use them for filtering; the <property> nodes we must modify are principally CommonViewFields and AdditionalFilterFields.

By default they are in this form:

<property name=”<name of property>” type=”string” />

For example

<property name=”CommonViewFields ” type=”string” />

In our case we modify as

<property name=”CommonViewFields” type=”string”>BA,MultiChoice;TipologiaIdent,Choice;LinkFilename,Computed</property>

Note that we must write the internal field name followed from the internal datatype, every field group is delimited from “;”.

Where to get internal name and datatype? In this case is very useful the SharePoint Manager 2007 , you point to the List / Document library in question and in the Schema XML tab you can read all the infos:


Or you can expand the Fields nodes and read the definitions field by field.

So we see that the field that is displayed as “Typology” has an internal name “TipologiaIdent” because the name was changed after creation.

Linkfilename is the name of the enclosed file for a Document Library , is corresponding to the “Name (linked to document with edit menu) ” field: we can see in SharePoint Manager that we have in a document library 4 fields named “Name” for example , that corresponds to 4 internal fields.

In every case you can sort the List /Doc library on the web page and observe the changes on http address , if there is a doubt which is the field:



In this MSDN blog post you can read a complete reference for MOSS internal field names.

In the AdditionalFilterFields property we can define the field name as it will be seen in the web interface:

<property name=”AdditionalFilterFields” type=”string”>TipologiaIdent,CITypology;BA</property>

That is we define that in the filtering fields we will see CITipology (Corporate Identity Typology) instead of the less understandable “TipologiaIdent”; BA has no renaming.

For the same reason we can rename fields with names more understable at XSLT level using the DataColumnRenames property :

<property name=”DataColumnRenames” type=”string”>TipologiaIdent,CITypology</property>

Done these changes, we can save the .webpart file and import our new CQWP.

Delete in the page the old CQWP where we was starting , click on “Add a Web Part” in a web part zone but this time we click on “Advanced Web Part gallery and options”


To the left appears the advanced interface where clicking on the down arrow we can expand the menu where to choose Import:

Image12

Clicking on browse we navigate the file system for the loading of our custom webpart:


Choosed the file by clicking on Upload we see that is available the new CQWP:


The new CQWP is placed on the web part zone by dragging the Uploaded Web Part (click on “Brochures” and start dragging, in our example) & dropping it on the “Add a Web Part” available zone:


Done this , we can choose “Modify Shared Web Part” from the CQWP edit menu, and see that now are available for filtering our custom fields:


Note that the new fields are positioned above all other fields.

In our .webpart we can set default filters by using the FilterType<n>, FilterField<n>,FilterValue<n> properties , with <n> from 1 to 3, that corresponds to the 3 available filters in the web interface.

For extremely complex query we can use the in the .webpart file the QueryOverride property: in this case we can write an CAML query without limitations, for example:

<property name=”QueryOverride” type=”string”><![CDATA[<OrderBy><FieldRef Name=’MyVersion’ Nullable=’True’ Type=’Number’ Ascending=’True’/></OrderBy><Where><Eq><FieldRef Name=’Title’/><Value Type=’Text’>SORB AC General</Value></Eq></Where>]]></property>

By using this property you will not have available some properties in the CQWP setting:


Using QueryOverride the “Additional Filters” and “Grouping and Sorting” sections becomes readonly.

The same message using other properties , for example ListOverride:

<property name=”ListsOverride” type=”string”><![CDATA[<Lists><List ID=”799399FA-8B0E-11E1-8271-5CDFBAE59B18″/><List ID=”<other guid>”/></Lists> ]]></property>

These are the GUIDs of your lists that you wish to restrict the query to.

Useful link:

http://msdn.microsoft.com/en-us/library/aa981241%28v=office.12%29.aspx

The very sad notice is that the filtering of custom fields with types “Text” and “Computed” does not work: in this case you are constrained to use a QueryOverride.

Very hurting, but i have tried and is true for MOSS 2007; for not custom Text fields (Title for example) instead it works: another post confirm this problem.

Could be that a future patch fix this issue.

In my next post i will write about the CQWP item style customization.

Advertisements
Categories: SharePoint
%d bloggers like this: