Comments on: Inconvenient Content Query Web Part vs. Lookup fields with multiple values

By: Mud83

Mud83 — Thu, 25 Mar 2010 19:05:44 +0000

Ram is just a example. It is value of the list.

But now I am calling the list by changing the common view field property and defining the list in the itemstyle.xsl file.
Anyway thanks.

By: Waldek Mastykarz

Waldek Mastykarz — Thu, 18 Mar 2010 15:56:39 +0000

@Mud83: Ram is not a valid CAML query. Is it literally what you're uploading or was it just an example?

By: Mud83

Mud83 — Thu, 18 Mar 2010 11:36:21 +0000

I want to embed a CAML query in the CQWP.
I am doing that by changing the queryoverride property.
eg – "

By: Waldek Mastykarz

Waldek Mastykarz — Sat, 06 Feb 2010 15:07:00 +0000

@Kevin: Unfortunately it doesn't change anything about working with Multiple Lookup fields. The reason why that cannot be changed has to do with how the query mechanism works: not really something we could do much about.

Custom XSLT function++: that would definitely mean subclassing the CQWP. Only that way it would be possible to create and hook up that XSLT function.

By: Kevin Gunther-Canada

Kevin Gunther-Canada — Thu, 04 Feb 2010 12:04:33 +0000

>I take it that this doesn't really solve the problem of querying for things based on values in the multiple lookup? That's a question that often comes up.

Andy: Embedding a valid CAML query in the XML of the web part usually gives us the ability to deal with the problem of querying Lookup columns with the CQWP. Interestingly, we found that when constructing the CAML, we had to make sure we the query uses (versus ) and the value type=text. FWIW, we have been using the CBQ Override (part of the Podcasting Kit) to simplify our use of custom CAML queries for the CQWP.

>Custom XSLT function++
Waldek: So am I understanding you to say that we can extract the XML returned from the query in the XSL template and potentially extract the values that way? Or is this requiring subclassing the CQWP somehow to achieve this result?

By: Waldek Mastykarz

Waldek Mastykarz — Fri, 17 Jul 2009 16:26:02 +0000

@TJ: that would be a viable solution as well. Moving the performance penalty from the item load to item edit is definitely a nice idea. Surprisingly I thought of something similar and wanted to use a calculated column for that purpose. Unfortunately, calculated columns don't support MultiLookup fields as well.

@Andy Burns: it doesn't solve the problem indeed. If you're looking for a solution for filtering the data, TJ's solution might be the thing for you.

By: Andy Burns

Andy Burns — Fri, 17 Jul 2009 13:55:12 +0000

Interesting, especially the extending the CQWP and XSL functions. I take it that this doesn't really solve the problem of querying for things based on values in the multiple lookup? That's a question that often comes up.

By: TJ

TJ — Fri, 17 Jul 2009 13:13:38 +0000

Not perfect either but another solution could be to add a hidden field to the content type which is updated using item events. The event can update the field to show the textual representation of the multi column lookup field. This field could then be formatted using the XSLT.