By default, we are able to display query results in our own page with the Search Core Results web part .  Basically the search query can be built in two ways:

• UserQuery: to get a query from current user we need a Search Box or Advanced Search Box web part. After typing the query, both of these webparts give the query to the URL QueryString, and the Search Core Results webpart show the results according to these parameters.
  For example: http://mymoss/sites/customsearch/default.aspx?k=42 means the user typed the query "42".
• FixedQuery: If we want to display results from a fix query, without user interaction, we can set the webpart parameter "FixedQuery" of Search Core Results.
  For exaple we can display all of presentations with extension ppt or pptx.

Unfortunately we don't have possibilities to build FIxedQuery dinamically, without programming. We can create a new webpart which inherits from Search Core Results, and override the FixedQuery, but it needs development efforts.

It would be nice to do this when e.g. we want to know who has birthday today, or what documents are checked out to the current user. These are very simple questions, can be typical queries with other scenarios as well.

Dynamic query

In my example I will build the query by the current URL. I'd like to know what contents link this URL in an other site collection.

Our search settings are scopes are ready to use, we need just build the query and display the results.

Let's go! On your current site create a Search Core Results webpart, but DON'T set it to FixedQuery! Here is the surprise: I'm going to use the UserQuery mode, without search boksz or any input field. If we can set the query string parameters in the URL (see above), the results are shown in the Results webpart (42). OK, but how can we set this "k" parameter automatically, without user input and programming?

The first thing we can imagine: insert the parameter into the links referred to this site. The idea is good, but we have two problems with it:

• It's definitely not too nice if we create URL with long parameters, that could be calculated automatically.
• We can insert the parameter into our own links, but inside the SharePoint it won'be work. For example we use the breadcrumb navigation, the parameters won't be inserted to end of our site's URL.

Well, what can we do? We could insert the parameter's creation into the given site, but without user input. The most optimal solution would be if we can build the creation into the Search Core Results itself.

The solution: edit the XSL behind the Search Core Result webpart! In this XSL, we can find the parameters of displaying, and the text rendered if the results set is empty ("No results matching your search were found."), or if the parameter is empty or missing. We can profit from it!

Look for the following part of the XSL:

   1:  <xsl:template name="dvt_1.noKeyword">

   2:  <span class="srch-description">

   3:   

   4:  <xsl:choose>

   5:  <xsl:when test="$IsFixedQuery">Please set the 'Fixed Query' property for the webpart.</xsl:when>

   6:  <xsl:otherwise>Enter one or more words to search for in the search box.</xsl:otherwise>

   7:  </xsl:choose>

   8:   

   9:  </span>

  10:  </xsl:template>

This part of XSL is responsible for handling empty parameters. The 'otherwise' tag handles FixedQuery - but it doesn't fit to our needs, so let's see the first, xsl:when branch. If we don't have any query (yet), so the parameter 'k' is missing from the Query String, the following tag will be active:

   6:  <xsl:otherwise>Enter one or more words to search for in the search box.</xsl:otherwise>

Well, how can we persuade the WebPart to fill in parameter 'k' automatically instead of display this message? Tadadaaa! Javascript! We're building the query in Javascript, build the full URL with requeires QueryString, and redirect the current page to this one. After redirection the XSL will go to an other tag, because the parameter 'k' won't be empty! 

   1:  <xsl:otherwise>

   2:  <script type="text/javascript">

   3:   

   4:  var kparam = location.pathname.substring(location.pathname.indexOf("site_"), location.pathname.indexOf("/Default.aspx"));

   5:  window.navigate(location.pathname + "?k=" + kparam);

   6:   

   7:  </script>

   8:  </xsl:otherwise>

Fortunately, we can do almost everything on client side by Javascript, so we can build our query by many other parameters. Very nice, isn't it?