9 Replies Latest reply: Aug 15, 2006 1:44 AM by Wendy Tromp RSS

    Pagination Sub-template and table-less layouts

    fac586
      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.
        • 1. Re: Pagination Sub-template and table-less layouts
          fac586
          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.
          • 2. Re: Pagination Sub-template and table-less layouts
            16414
            I would like to see this feature too.

            If the tags
            #ROWS_FETCHED#
            #TOTAL_ROWS#
            #FIRST_ROW_FETCHED#
            #LAST_ROW_FETCHED#

            would be available in the Pagination Template part would help alot
            • 3. Re: TOTAL_COUNT : request for enhancement
              I-P
              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.
              • 4. Re: TOTAL_COUNT : request for enhancement
                Wendy Tromp
                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..... :(
                • 6. Re: TOTAL_COUNT : request for enhancement
                  369783
                  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

                  Bill Ferguson
                  • 7. Re: TOTAL_COUNT : request for enhancement
                    Wendy Tromp
                    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.
                    • 8. Re: TOTAL_COUNT : request for enhancement
                      VANJ
                      Wendy: Did you try using the 'search engine' style pagination scheme? That would seem to do what you need. It shows the pagination sets like
                      1-15 16-30 31-45 ...
                      That gives a pretty good idea of the number of "pages" in the result set, doesn't it?
                      • 9. Re: TOTAL_COUNT : request for enhancement
                        Wendy Tromp
                        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"