Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Refactor access to category/tag names #29

Closed
ghost opened this Issue · 13 comments

4 participants

@ghost

Adding a sorted array with all available category names as 'site.categorynames'. This allows to set up a listing of all categories.

Please pull from my repository (commit b659e9ce34cb74129650fc3e37ee5000328e9d8d).

@qrush

I like this, but it definitely needs tests. On hold until someone can get around to writing them.

@h3h
h3h commented

Might I humbly suggest category_list instead of categorynames?

@ghost

Done: 98a468355fb1ce30b0868400963ea5fc44a66f48

@tomjack

Why not rework site.categories to accomplish this? So we can do like:

{% for category in site.categories %}
  <h2>{{ category.name }}</h2>
  {% for post in category.posts %}
...
@ghost

Initially I just needed a small fix for my site. A one-liner seemed like a good-enough solution for the time being. I initially even set out to implement Thomas idea but was too lazy, so I stuck with the one-liner.

That said, I think that a bit of re-modeling might benefit jekyll in the future (i.e. decoupling filesystem layout and reading from content transformation, changing Topic and Category into real objects, etc.).

@tomjack

I was able to make the snippet in my last comment work, but in order to keep site.categories.foo working, I had to make a Categories class that acts both like a hash (mapping category names to Post arrays) and like an array of Category objects (through each).

This seems like it would become more of a problem if categories ever get more data. I'd like to be able to someday do:
{{ category.name }}
and have it link to an automatically generated _site/[category]/index.html. But if site.categories.foo is an array of posts, the extra category data won't be accessible from it.

Maybe we could change site.categories.foo to site.categories.foo.posts?

@qrush

Alright, now that tags are in master I think it's time to address this issue. I like tomo's idea but I need to play around with this more. If you've got other suggestions pipe up!

@qrush

If this was to be refactored, I think it would need to degrade gracefully. For instance I think at least until 0.6.0 or 0.7.0 the site object would have to work as normal. There could then be a new object, perhaps jekyll or another name that makes sense with the refactored payload.

Or maybe this could be done through a config value... payload: new and default to old, print out plenty of warnings in the meantime.

@ghost

I really like tomos idea. I like to have a strong domain model at the heart of my programs and his idea goes along the same lines. My suggestion is: Follow tomo and drop site.categories.foo in favor of site.categories.foo.posts.

@ghost

Btw: I created a wiki page (http://wiki.github.com/mojombo/jekyll/thoughts-about-a-new-version ) that discusses API-breaking changes. Please contribute to the page.

@parkr
Owner

I think we're good on this, no?

@qrush

This is super old. Closing it down.

@qrush qrush closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.