Pagination about gostatic HOT 25 CLOSED

That seems like a good idea to me. I'm not sure if I'll do that in next few days, but I'll try to look into doing something like that. I'm not sure how to represent this better without introducing new concepts though... Maybe it's ok to put pages in .Other.Pages, or maybe it worth it having a middle ground between Site and Page (like, SubSite or something like that).

from gostatic.

Jekyll uses "paginator" as the term (e.g. .Paginator.Pages, .Paginator.Next, etc.). Could also go the route of .PageGroup or .MatchedPages?

from gostatic.

Hey! I did some implementation, and hopefully it will work for you - haven't tried it on a proper site yet. See config and templates for an example. I've also added some docs to readme.

Please report if you have any problems with that.

from gostatic.

Awesome @piranha! I'll check it out soon.

from gostatic.

Pagination is looking good so far. Only concern now is the sort order - would it make more sense to sort by date in descending order (newest first)? In all cases I can think of, sorting in this way would be more useful (getting the latest post, latest n posts, or the next page of posts).

from gostatic.

Also, it would be mighty handy to have "next", "current" and "previous" page numbers (and URLs, if possible) available in the paginator so that they can be linked from within each "listpage" template.

The end goal is a navigable flow like:

• page 1
  • next (linked to page 2)
• page 2
  • back (linked to page 1)
  • next (linked to page 3)
• page 3 (last page)
  • back (linked to page 2)

from gostatic.

Hmm.. how is it sorted right now? As for current/next/previous - that's a good one, I absolutely forgot about it. :)

from gostatic.

I am seeing it sorted by date, but oldest on page 1 rather than newest.

On 12/05/2015, at 12:15 am, Alexander Solovyov [email protected] wrote:

Hmm.. how is it sorted right now? As for current/next/previous - that's a good one, I absolutely forgot about it. :)

—
Reply to this email directly or view it on GitHub.

from gostatic.

Ah! That's funny, I'll reverse them. :)

from gostatic.

Ok, so I've got the them and now there is a paginator object, where you can get prev/next pages, and paginator pages are actually sorted!

I'm not entirely happy with the code, haha, but then it's not super ugly, plus works well enough. At least it seems so to me right now.

One thing I'm really unhappy about is that you have to call paginator global function to get access to your paginator object, but I can't find a way around Go's type system to pass around context object bigger than just Page without making every part of the system aware of pagination (which I don't really want to do).

So, feedback wanted! :)

from gostatic.

@piranha Just did another run through with the latest master and it seems to work great!

I'm not sure if this issue is related to your comment about the global paginator function, but I'm getting weird range errors when running your example template within two different patterns/rules on the same set of paginator pages. See this config:

posts/*.md:
    config
    paginate 10 pages/*.page
    ext .html
    markdown
    template post
    template page

pages/*.page: posts/*.md
    rename ../page-*
    ext .html
    directorify
    template archive
    markdown
    template page

pages/1.page: pages/*.page
    rename ../index.html
    template archive
    markdown
    template page

What this is doing (or what it's supposed to do) is paginate all of my blog posts, then convert all of the paginator pages into actual pages (archive uses your exact listpage template). Then for page 1, rename to index.html so that it can be used for the blog's homepage.

However, when I run this, I get:

Error: pages/2.page: runtime error: index out of range

This specifically seems to happen for the pages/1.page rule and specifically for this line of the template:

{{ if .Prev }}<a href="{{ $.UrlTo .Prev.Page }}">prev</a>{{ end }}

In theory, this line should get skipped because there's no previous page when on page 1. Removing this line from the template allows the site to compile without error. And, more specifically, replacing {{ $.UrlTo .Prev.Page }} with a hardcoded path using {{ .Prev.Number }} also allows the site to compile without error.

I can separate the index page into its own template (instead of relying on archive), but hoped this would work. (Just tried, but this doesn't work either) Any thoughts on this?

from gostatic.

That's quite strange. Can't reproduce this... Look at the last commit, do you have any difference to that? Or maybe your site code is open sourced somewhere, so I can try gostatic on it and debug the problem?

from gostatic.

@piranha I put my work in progress up here: https://github.com/iwantmyname/blog/tree/gostatic (in the process of converting from Jekyll, so don't mind some files here and there that aren't actually in use)

I also realized in my tests that pagination in the way that gostatic sites are currently built can't really replace the way Jekyll enables certain things like excerpts.

Take this for example from the Jekyll site:
https://github.com/iwantmyname/blog/blob/master/_includes/excerpt.html

That file creates a conditional excerpt based on the post content before it's rendered into HTML with layouts, etc. That excerpt is then used here:
https://github.com/iwantmyname/blog/blob/master/_includes/post-preview.html

The post-preview is used to create the listing of articles on the paginated pages (archive).

I guess this case would need some sort of excerpt plugin to extract and render the excerpt separately to be included in the archive page listing?

from gostatic.

Well, there is a cut global function, so you can do cut .Content "^" "<!-- more -->" (or same with beginning/end). You can create separate template (like {{ template "excerpt"}}...{{end}}) and then render your excerpt with it. The only thing missing is contains function, but that one is easy to add, I'll do that right now.

P.S. I think I failed a bit with arguments order regarding Go's template pipelines - not sure what to do now. :)

from gostatic.

@piranha I'm not too worried about actually creating the excerpts. I think the problem is that using cut etc. will be using the full, rendered HTML page instead of the original Markdown on the paginated pages. Does that make sense?

from gostatic.

Ah! That does make sense... Hm, yeah, not sure what to do. I guess I could create a new method on a Page, which will return what's needed, but the question is - what should it do? .Excerpt doesn't make a lot of sense - it's too narrow.

I've got another idea - maybe .Content should have it's counterpart, like .Source and .Path. Any thoughts? Especially about name. :-)

from gostatic.

Including the original, unprocessed contents in the Page would be great!

How about .OriginalContent, .RawContent, or .ContentSource?

from gostatic.

Maybe even just .Raw?

from gostatic.

That works too.

from gostatic.

Well, give me 15 minutes. :)

from gostatic.

@holic it's in, please try and tell me if it's good enough. :)

from gostatic.

@piranha Can we also override the .Raw content when the config header is parsed? Since the config header is essentially page metadata, it shouldn't be included in the .Raw content (because it'll already be available in the Page struct).

from gostatic.

Hmm... yeah, that would make sense, but then what if there is no header? I mean... how do I decide what's Raw and what's not? Let me think a bit, maybe I should put .Raw there after all preprocessors... I'll try to invent what to do before you're awake. :-)

from gostatic.

Hey, it actually made quite a bit of sense. config is only one preprocessors that changed content, so... I've pushed changes, should work as you've described now. Check it please.

from gostatic.

👍 Works great!

from gostatic.