An individual search query can return a large number of results. Rather than displaying all of the results on
a single page, you will typically want to break them up into multiple pages, with a certain number of
items per page. Therefore, the query includes properties that you can use to specify the number of items
to include per page and which page to display.
This chapter describes these pagination properties and their effects. It includes the following topics:
Specifying the Page Size
Handling Page Requests
Types of Paging
Modifying and Resubmitting the Request
Specifying the Page Size
You use the pageSize request attributes to specify the number of items per page. For example, if
pageSize=10, the results will include ten items per page.
The following JSP fragment creates a drop-down for selecting a value for the pageSize attribute:
Page Size
<dsp:select bean="${FH}.searchRequest.pageSize">
<dsp:option value="100">100</dsp:option>
<c:forEach begin="5" end="35" step="5" var="pageSize">
<dsp:option value="${pageSize}">
<c:out value="${pageSize}"/>
</dsp:option>
</c:forEach>
</dsp:select>
Handling Page Requests
When you render the initial page of results, you typically want to render links to other pages of results.
Each of these links actually issues a new search query that in most respects is identical to the original
query, but which specifies a different page of results. So paging involves a sequence of connected
requests and responses.
To display a specific page of results, you set the form handler’s goToPage property to a 1-based page
number. The goToPage property has an associated handler method, handleGoToPage. When a user
clicks a link that sets the value of goToPage, the handleGoToPage method issues the search for the
specified page.
To ensure that all of the requests and responses in a sequence of page requests are associated with each
other, the initial query generates a unique String identifier called a request chain token. This identifier is
included in each query in the sequence of requests, and is returned in each response.
There are various paging options available, and the ones you use depend on the needs or your site. The
following options are explained below:
· The type of paging to use: normal paging or fast paging
· Whether to save the request in the search session or not
Types of Paging
ATG Search supports two types of paging, normal paging and fast paging. The key differences between
them relate to the information you get back from the search engine about the number of pages of results,
and the navigation you can build into your pages:
· Normal paging is the default. In this mode, the search engine returns (in the form
handler’s pagesAvailable property) the total number of pages of results. You can
create links that enable the customer to go directly to any page.
· Fast paging is specified by setting the fastPaging property of the search request to
true. In this mode, the search engine does not return information about the total
number of pages of results; pagesAvailable is set to the highest-numbered page
that has been rendered so far. You can enable customers to go to the next page or to
any page previously rendered.
For a single-partition index, normal paging is always enabled (the fastPaging property is ignored). For a
multi-partition index, you can choose between normal paging and fast paging, but fast paging is
recommended. Fast paging is much less resource-intensive than normal paging. On multi-partition
indexes, normal paging can be very memory- and CPU-intensive, because results from the partitions must
be merged.
Example of Normal Paging :
The following example renders a list of the page numbers of all pages of results. Each page number is a
link to the corresponding results page, except for the current page number, which is displayed without a
link. For example, if pagesAvailable is 43 and the current page is page 10, this code will render the
integers from 1 to 43, and all of these except 10 will be links. If the user clicks 22, for example, a request to
display page 22 will be issued.
<!-- Indicate that the request should be saved in the search
session so that initial request data, such as the question
text, is available to subseqent paged requests. -->
<dsp:input bean="QueryFormHandler.searchRequest.saveRequest"
value="true" type="hidden"/>
<!-- Display page numbers with links to take user to specified
page -->
Go to Page:
<c:forEach var="page" begin="1" end="${formHandler.pagesAvailable}">
<c:choose>
<c:when test="${page == (1+formHandler.searchResponse.pageNum)}">
${page} <!-- The current page, don't display a link -->
</c:when>
<c:otherwise>
<dsp:a href="normal-paging.jsp">
${page}
<dsp:property bean="QueryFormHandler.searchRequest.requestChainToken"
value="${formHandler.searchResponse.requestChainToken}"/>
<dsp:property bean="QueryFormHandler.searchRequest.saveRequest"
value="true"/>
<dsp:property bean="QueryFormHandler.goToPage" value="${page}"/>
</dsp:a>
</c:otherwise>
</c:choose>
</c:forEach>
Example of Fast Paging
The following example renders a list of the page numbers of the results pages that have been rendered so
far. Each page number is a link to the corresponding results page, except for the current page number,
which is displayed without a link. In addition, the example renders the word “more” as a link to the page
following the current one.
<!-- Turn on fast paging -->
<dsp:input type="hidden" value="true"
bean="QueryFormHandler.searchRequest.fastPaging"/>
<!-- Indicate that the request should be saved in the search
session so that initial request data, such as the question
text, is available to subseqent paged requests. -->
<dsp:input bean="QueryFormHandler.searchRequest.saveRequest"
value="true" type="hidden"/>
<!-- Shortcut to the response object, which may be null -->
<c:set var="response" value="${formHandler.searchResponse}"/>
<!-- Display page numbers with links to take user to specified
page -->
<c:if test="${response != null}">
on page: ${1+response.pageNum}<br/>
Go to Page:
<c:forEach var="page" begin="1" end="${1+formHandler.pagesAvailable}">
<c:choose>
<c:when test="${page == (1+response.pageNum)}">
${page} <!-- current page -->
</c:when>
<c:otherwise>
<dsp:a href="fast-paging.jsp">
<c:choose>
<c:when test="${page == (1+formHandler.pagesAvailable) &&
response.multiPartitionSearch &&
formHandler.searchRequest.fastPaging}">
more
</c:when>
<c:otherwise>
${page}
</c:otherwise>
</c:choose>
<dsp:property bean="QueryFormHandler.searchRequest.requestChainToken"
value="${formHandler.searchResponse.requestChainToken}"/>
<dsp:property bean="QueryFormHandler.searchRequest.saveRequest"
value="true"/>
<dsp:property bean="QueryFormHandler.goToPage" value="${page}"/>
</dsp:a>
</c:otherwise>
</c:choose>
</c:forEach>
</c:if>
Modifying and Resubmitting the Request:
Since subsequent requests differ only in the requested page of results, it is most efficient just to retrieve
the most recent search request, change the value of the goToPage property, and resubmit the request.
There are two ways to do this:
· Modify properties on the form, and resubmit it. This avoids the memory use required
to save the request in the SearchSession. The downside is that resubmitting the
form is difficult if you are creating your links through anchor tags. In that case, it is
generally easiest to write a JavaScript function that makes the necessary changes and
submits the form.
· Save the request in the SearchSession. This allows you to retrieve the request,
modify it, and reissue it; no JavaScript is necessary. The downside is that this approachcan
use a lot of memory, especially if there are many users at your site issuing search
queries.
Note that resubmitting a modified request is useful for faceted search as well as for paging.
Example of Resubmitting the Form:
If you do not want to save the request in the SearchSession, you will need to resubmit the form. Create
a JavaScript function like this:
function nextPage(pageNum, requestChainToken)
{
document.searchForm.requestChainToken.value = requestChainToken;
document.searchForm.goToPage.value = pageNum;
document.searchForm.submit();
return false;
}
You can then invoke the function when the user clicks on a link for a specific page:
<a href="#" onclick="return nextPage('<%=pageValue.toString()%>',
'${formHandler.searchResponse.requestChainToken}');">
<dsp:valueof param="count"/>
</a>
When the link is clicked, the page number associated with the link and the requestChainToken of the
current search response are passed to the function. The function uses these values to set the goToPage
property and the requestChainToken property of the form, which it then submits. In addition to
specifying the results page to display, this ensures that the same requestChainToken value is associated
with each subsequent search request.
Example of Saving the Request in the SearchSession
If you save the request in the SearchSession, you can avoid the use of JavaScript. Instead, when a user
clicks on a link for a page, you set the necessary properties (including the saveRequest property) on the
saved request through dsp:property tags, and then resubmit the request:
<dsp:a href="queryExampleFastSave.jsp#Paging">
<dsp:valueof param="count"/>
<dsp:property bean="QueryFormHandler.goToPage" paramvalue="count"
name="fh_gtp" priority="29"/>
<dsp:property bean="QueryFormHandler.searchRequest.saveRequest"
value="true" name="fh_sr" priority="30"/>
<dsp:property
bean="QueryFormHandler.searchRequest.requestChainToken"
value="${formHandler.searchResponse.requestChainToken}"
name="fh_rct" priority="30"/>
</dsp:a>
