• View
• Edit
• History
• Attach
• Print

00689

Description: Pagelist directives has a count= argument allowing one to limit how many pages are listed. You can use negative numbers to pick the last ones instead of the first ones (which as I understand do not change the order, governed by the order= parameter).

Very flexible, but it does not allow one to list pages in the middle of the list. Therefore, something like a skip= argument should be added which would make the pagelist not include the first n entries in the list.

This feature would potentially be useful to paginate pagelists.

Should it be "skip=" (skip n entries) or "first=" (start with n as first entry)?

--Pm

Or perhaps a "start=" (start with 'n' as first entry).

What this is edging towards is something which could give us paginated search/pagelist results. That is, to be able to say "I want multiple page results, with N results per page". At least with a skip/first option, one could do this by hand as follows:

PageA would have

[[PageB]]
(:pagelist first=1 count=20 ... :)

PageB would have

[[PageA]] | [[PageC]]
(:pagelist first=21 count=20 ...:)

PageC would have

[[PageB]]
(:pagelist first=41 count=20 ...:)

But this doesn't really go far enough, since one would miss out on all the results one didn't make pages for, which is a problem since one doesn't usually know how many search results one is going to have in advance.

Kathryn Andersen August 04, 2006, at 07:21 PM

Or how about an increment approach using a new increment argument, or, better yet, a new increment function that would use the existing count argument to specify the number of items, coupled with a new variable to track and promote or demote an increment value in response to a new action link.

• For example, (:pagelist count=20...:) would continue to return only the first twenty items, but it would do so because it was processing an initial default increment value of 1 (or 0).
  • That default value could exist only in the script, or it could be exposed to the author as an argument, so that the default value could be changed (increased by one to start with the next batch of 20 items)
• A new action (or actions) could be used to enable a pagelist to display links at the end of a batch to trigger the "next" or "prior" batch of 20 items.
  • As links, they could be aliases to whatever name was preferred (next, more...) or could use an image.
• Practical applications. The first thing I would use something like this for is a pagelist image gallery (that I'm working on now) to allow a large group of pagelisted thumbnail links to be automatically broken down into batches according to the desired size of the thumbnail grid being used (e.g. set count to 9 for a 3x3 thumbnail grid, or 16 for a 4x4 grid, etc) Pico August 22, 2006, at 08:24 AM

This all sound great, but who cares about paginated searches when searches are still basically just a list of pages? Sure, there are some recipes that make things a bit better, and there is some stuff you can do on your own... But the only //good// place I can see this pagination helping now is when you want to use a ton of includes in your pagelists.