New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve routing #100

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@ljanyst
Contributor

ljanyst commented Nov 21, 2015

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 comment has been minimized.

Owner

kingcons commented Nov 21, 2015

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

This comment has been minimized.

Contributor

ljanyst commented Nov 22, 2015

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment