Improve routing

[ljanyst]

Here's a bunch of improvements to content routing that I find useful.

1. Blog index

I want my index.html to be a static page and, if I do so now, the first page of the numeric index gets overwritten. This is because coleslaw creates a symlink from index.html to the first page of the numeric index. This change allows you to specify a custom name or nil for the blog index.

2. Point the blog index to the first page of the numeric index irrespective of the routing settings

This fixes the bug where the code assumes that the first page of the numeric index is always called 1.html. However, this may not be be true, depending the routing settings.

3. Allow for lambdas in routing settings

I really like having something like this:

 :routing ((:post           (lambda (document)
                              (format nil "posts/~a-~a"
                                      (subseq (coleslaw:date-of document) 0 7)
                                      (coleslaw:slugify (coleslaw:title-of document)))))
           (:tag-index      "tag/~a")
           (:month-index    "date/~a")
           (:numeric-index  "post-index-~d")
           (:feed           "~a.xml")
           (:tag-feed       "tag/~a.xml"))

[kingcons]

This is interesting (and good functionality) but I'm wondering about better solutions to two issues:

A) The fact that we give numeric indexes special treatment in the first place. (E.g. instead of having a /page/~A.html or similar route.)
B) The use of eval makes me think we might want some more dedicated extension point here. I can sympathize with the desire for functions in routing.

I'm going to spend a little time thinking about these. Thanks for sparking this discussion.

[ljanyst]

a) I am not sure what you mean. I think it's pretty good the way it is, because it gives you quite a bit of flexibility in defining the layout of the rendered result. I don't really see how you could unify the routes and not pay the cost of limiting the flexibility.

b) Well, you could use either functions or templates (I mean something like: "%{hour}-%{title}") here. I would argue that functions give you more flexibility. I was thinking about doing it as a plug-in, but decided against for two reasons:

1. These will typically be pretty trivial mappings of document properties onto strings, so lambdas are sufficient.
2. If you did it as plug-ins, it would be more handy to allow such plug-ins to live in the content repo (see my patch concerning user themes). This will be something I will look at anyways. I am migrating one of my websites away from jekyll and have quite a bit of custom code.

[guicho271828]

I think it is nice to merge this and consider the better solution later.

[guicho271828]

the second commit (renaming the accessor) is unnecessary and inconsistent with other accessors.

[guicho271828]

(or is it?)

[guicho271828]

the usage for 1. is unclear.