Having looked through the documentation and forum postings I've come to the conclusion that the pagination sub-templates are internally generated using HTML tables and there's no way to change this at template or application level. Is this correct?
Help states that "[#TOP_PAGINATION#] substitution string generates HTML which starts with an opening <tr> tag and ends with a closing </tr> tag", meaning that #TOP_PAGINATION# - which already generates a table for its contents - has to be wrapped in another table serving no purpose whatsoever.
We'd like to avoid any unnecessary use of HTML tables in layout for accessibility reasons - particularly nested tables. If there's no way round this at present, please consider making the structure of pagination sub-templates more customizable in future releases.
After looking at the report region output again I see from the colspan=... attributes that the intention is probably to make the pagination areas part of the report table, and I've amended my customized template accordingly. Still like to be able to control the structure of the pagination sub-template though - might not want to make it a table.
I agree with that : That would be a request for enhancement.
I would like to display #TOTAL_ROWS# as part of a report header, eg :
" Your search returned #TOTAL_ROWS# hits " .
I don't see any performance benefit running a "super Nested query" twice , ie once to return the count(*) and one more time to generate the actual report.
Also, count(*) is exact count and can be confusing when displayed if count(*) > "Max Row Count"
It's kinda useless that #TOTAL_ROWS# works only in the footer.
But I am OK with Displaying the Total# hits at the footer for the time being.
I'd like to show the total number of pages in the footer. I can show the number of hits, and I have a page item that contains the number of rows per page but computing the number of pages seems pretty impossible.
If there was a pagination scheme for it i'd be even happier, but none of them tell me the total number of pages returned..... :(
Since it seems that you need to do an extra query to generate the count(*), for the total number of pages, just divide that by 15, or whatever your page display size is.
I.e., Total_pages = count(*)/15
I think it's quite silly to have to use an extra query, since I can display the total number of hits in the pagination and I also know the number of items per page, but no process can be created to combine the two into the total number of pages....
I think it'd be a good idea to create new pagination schemes in newer releases that do show the total number of pages.
The search engine style here shows page 1,2,3,4 and a link to the next set. With 1800 results and a page size of 20 it's a long way to know how many hits you got or how many pages there are.
You are probably talking about the Row Ranges pagination style which shows a link to the next few sets but again, at 1800 hits this does not suffice. For now I am using "X to Y of Z with set pagination" so that the user can at least see the number of hits and determine the number of pages himself.
By the way: when I use the Row Ranges with select list and the number of sets is larger than 500, the select list disappears and the layout of the pagination is the same as "X to Y of Z with set pagination"