Refactor access to category/tag names about jekyll HOT 13 CLOSED

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

from jekyll.

Hi, I created a branch with tests: http://github.com/Jens-n/jekyll/tree/test_categorynames

from jekyll.

Might I humbly suggest category_list instead of categorynames?

from jekyll.

Done: 98a468355fb1ce30b0868400963ea5fc44a66f48

from jekyll.

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 %}
...

from jekyll.

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.).

from jekyll.

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?

from jekyll.

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!

from jekyll.

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.

from jekyll.

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.

from jekyll.

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.

from jekyll.

I think we're good on this, no?

from jekyll.

This is super old. Closing it down.

from jekyll.