hitlist_contracts
Break-down of flow
The request goes through the following stages:
browser 1 -> search-entries.xq - create one XInclude for each selected collection 2 -> search-coll-entries.xq - this is where the real search is done 3 <- return original XML wrapped in <query-results>, in small chunks search-coll-entries2html.xsl - transforms original XML to standardised XML - wraps up everything in a <div id="CollID"> 4 <- search-entries2html.xsl - all searches now collected and wrapped in XML from search-entries.xq - transforms the XML to final HTML 5 <- browser
Below we'll go through each step, and comment them in turn. The numbers at the arrows correspond to the sections below.
1 search-entries.xq
This XQuery simply breaks up the list of selected collections, and creates one XInclude element for each, adding the collection as a new request parameter. The XIncludes are then processed by the sitemap.
Further details in the architecture section.
2 search-coll-entries.xq
This is were the real search happens. This script builds the search using available request parameters, and returns chunks of the total result-set. The XQuery itself can be located in three places, and is searched for in this order (the path is only an example):
- collection-specific: query/terms/SD-terms
- type-specific: query/terms
- general: query
The most specific search will be used. The search results are wrapped in the following XML:
<section title="ID" id="ID">
<header>
<style href="risten_query_terms_ID.css"/>
</header>
<query-results collection="{$coll}" hits="{$count}" start="{$start}"
next="{$end + 1}" max="{$max}">
<!-- THE REAL, RETURNED XML fragments go here -->
</query-results>
<p class="srchtime">0.123</p> <!-- The search time here -->
<section>
The search results should be stored in a collection-specific session parameter. This is different from the old solution in that there was only one session parameter for all search results. To be able to browse back and forth individually in each collection, we need one session parameter for each collection. We'll see if this uses a lot of memory, and if that's a problem.
3 search-coll-entries2html.xsl
This script transforms the returned XML to a standard format. The format needs to follow these guidelines:
- the collection ID should be inside <section title="ID"> (? - or as table caption?)
- the result itself should be wrapped in two tables:
- one outer, containing only two rows - header and body
- the header contains browsing links, number of hits, and ID
- the body contains the rest
- the inner table, in the second row of the outer table, contains the acualt hits, with links to full entries, etc. This table is formed according to the needs of the data in question, but it should be similar across collections
- one outer, containing only two rows - header and body
- if a collection returns no hits, there should be no output (I think)
That is, the structure should be the following:
<section title="ID" id="ID">
<header>
<style href="risten_query_terms_ID.css"/>
</header>
<table>
<caption>
<span class="id">ID</span> <!-- Left-align -->
<span class="count"># of hits</span> <!-- Right-align -->
</caption>
<tr>
<th>Prev X</th>
<th>Summary</th>
<th>Next X</th>
</tr>
<tr>
<td colspan="3">
... [whatever is most suitable for the collection in question]
</td>
</tr>
</table>
<section>
4 search-entries2html.xsl
The final step is to convert the document holding all results into HTML. Mostly turning the DocBook-like structure into HTML, as is done today.
The outer structure is the same for all pages:
<body> <h1>Hits</h1> <!-- page header --> <table>...</table> <!-- one table for each collection with hits --> <table>...</table> <table>...</table> <p class="srchtime">Ohcan ádjánii 0.001 sekundda.</p> </body>
This XSL is also responsible for collecting all CSS references, and include them in the header of the HTML page.
5 serialisation to browser
Not much to say - the constructed HTML is searialised as a byte stream, and returned to the browser.