|
From: Norman Y. <ya...@ya...> - 2012-03-16 20:54:31
|
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. |