Re: [Pyblosxom-devel] Patch for pagination in static-rendering mode

[Norman Y. <ya...@ya...>]

Most of the code I added can easily be moved out to a plugin, since it
falls under the cb_truncatelist callback which the existing 'paginate'
plugin uses.  (That's why that plugin should still work.)

The remainder of what I added is core infrastructure that would probably
be necessary to support pagination under static rendering however it was
done.  Without it, a plugin would have to find some way to add more files
to the list of files to be rendered statically, when it found that an
index page overflowed, and to do that in the middle of said rendering.
(I didn't see a callback that would permit that, but perhaps there is
one.)  Then some other piece of code would have to detect that the page
to be rendered is a followup page, and render it accordingly.  It's
simpler to just add a loop in the static-rendering code that iterates
through the followup pages, passing down a variable which indicates 'now
render followup page N', which is what I did.

I considered moving the code that falls under cb_truncatelist out to the
existing paginate plugin, but thought that the way I did it was better in
line with the existing ethos of the program: provide basic functionality
in the core, but let a plugin override it if they want to do something
fancier.  The present behavior of just dropping entries off the ends of
index pages unless the user installs a plugin seems unnecessarily
unfriendly.

The two decisions that the code I added bakes into the core are (1) the
filenames for the followup pages under static rendering (I chose
"filename_pageN.html") and (2) the fact that the way that pages are split
up is by putting a fixed number of entries on each subpage, that number
being given by the config variable num_entries.  Perhaps someone would
want something different, with one of those, but they're not like the
appearance of the navigation string in the output, where someone
definitely will want something different (and which a plugin could
change).

So please reconsider adding it.

On Fri, Mar 16, 2012 at 07:21:27AM -0400, will kahn-greene wrote:
>I don't think it should be in the core. It's less an issue of "who 
>would never use pagination" and more an issue of "are there different 
>kinds of pagination behavior and thus should be supported in plugins". 
>So I'm -1 on adding this to the core.
>
>I'll toss this and the patch into the issue tracker at some point and 
>someone can look at absorbing the changes into the pagination plugin.
>
>/will
>
>
>On Fri 16 Mar 2012 05:03:34 AM EDT, Norman Yarvin wrote:
>> Attached is a patch that enables pagination in static-rendering mode,
>> pagination being the rendering of index pages which are longer than
>> num_entries by writing them out to multiple pages, combined with the
>> production of navigation strings which the user can include in the
>> templates for those pages.  Since:
>>
>> 	-- doing this as a plugin seemed somewhere between painful and
>> 	impossible, and
>>
>> 	-- I think this really should be core functionality anyway,
>>
>> I went ahead and implemented the whole thing in the core.  It should work
>> for dynamic rendering, too (or whatever one calls the opposite of static
>> rendering), but I haven't tested that mode.  It is meant to supersede the
>> present "paginate" plugin, but the latter should still work (again,
>> untested).  It uses all the same config variables, except for
>> "paginate_count_from", which I thought was far too much in the
>> bikeshedding direction to be worth saving.  The variable
>> "paginate_linkstyle" accepts, besides the old settings (0 or 1), the more
>> descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0).
>>
>> For static rendering, instead of the page number being sent in the HTML
>> query, as in
>>
>> 	http://example.com/blog/index.html?page=2
>>
>> it has to be part of the filename, as in
>>
>> 	http://example.com/blog/index_page2.html
>>
>> which is now this change does it.
>>
>> I haven't yet fixed up the documentation to reflect the changes.
>>
>> (As for why I think this should be core functionality, I can't imagine
>> anyone not wanting it, at least for normal weblog use.)
>>
>>
>>
>>
>>
>> This body part will be downloaded on demand.
>>
>>
>> This body part will be downloaded on demand.