SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why don't SharePoint standard search-related web parts use web part connections to communicate with each other? They use QueryManager instead which is placed into Page.Items. I'm trying to understand the tradeoffs here. Is there something that was impossible to achieve using connections?

share|improve this question
up vote 1 down vote accepted

I think the real reason is that the team that developed these controls initially didn't know how to use web part connections.

But it gives the following advantages (which MS probably will claim is the reason).

Easy setup on single query page
On most search pages users only have a single query. The current implementation makes it easy to add new search web parts as you can just add them to the page and they automatically use Query1 as all the others.
Most uses don't understand web part connections and this setup makes everything simple until you need a second query, but then you still only have to configure a simple setting on the second set of web parts.
And 5 queries on a page is enough for EVERYBODY, so what's the problem?

Don't rely on any search web part being on the page
The current implementation don't rely on any of the web parts to be on the page, you can mix and match any combination, if you only need a count the don't include the CoreSearchResult. Using connections this would be very hard to make possible.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.