Render tags in the packaged themes

[wbazant]

Looks the same as in v2 but hidden behind an extra if - tags are not fully supported yet (can't add them through Yancy UI) and anyway, better write nothing than Tags: for a post without tags.

[coveralls]

Coverage remained the same at 86.182% when pulling e4ee143f6ff3c5adb93c1da5b0c6ea1dbb902794 on wbazant:v2-tags-in-packaged-themes into e0f50d3b2e58aed49e2e9876acf482bb53fca097 on preaction:v2.

[preaction]

This is good, though the url /tag/$tag will no longer always be correct: It at least needs to be a URL under the blog.

But, now that you mention it, there's a difference between v0 and v2: In v2, content is not "owned" by an application. So, in v0, a blog post can ask the Blog app for the tag URLs it knows about and show them on itself. In v2, the blog post is not attached to the blog except via the links the blog creates. When the user gets to the post's URL, we no longer know what App they came from...

Off the top of my head, some possibilities for solving this problem:

1. Remove automatic tag pages and require the user to add it via template inheritance. Using extends in the template means it would require only a few lines of template, and they'd have complete control over what URL would be generated.
2. Look for the page in all the lists: Use the applications' categories to figure out where the current page would appear on the site. Probably make a method in the App class and then ask every App if they can see this page. If they can, the app returns a URL and some text to use for the link.
3. A global taxonomy system. Content all across the site would be able to be categorized/organized by this taxonomy. The configuration file would define a taxonomy: as a hash of hashes. The keys of this hash are identifiers, the values would be constraints to match. If the document matches a constraint, it's part of that taxonomy. Taxonomies could be assigned a URL which the user could set up as a landing page for that category of the site's content. We could set up some default for taxonomy pages, as well as a default taxonomy based on the blog's tags (find a blog app, use its tag pages).

    # Sample taxonomy configuration
    taxonomy:
        git:
            filter: { tags: 'git' }
            route: '/blog/tag/git'
        mojolicious:
            filter: { tags: 'mojolicious' }
            route: '/mojo' # custom page for mojolicious stuff
        tmux:
            filter: { tags: 'tmux' }
            route: 'app:blog/tag/tmux' # Call a method on the blog app to make the URL?

It may be that a combination of 2 and 3 is needed to really make this work, but it all seems very complex... It is just an application of the same principles as the list app and categories, so maybe it's not as difficult to understand as I fear? And, global taxonomies could do fun things like override templates / layout / other settings for the page.

For this early stage, this patch is good, and it'll remind someone that there's still some development needed here if it goes in (either by it throwing 404 errors or by someone reporting a bug :smile:)

[wbazant]

@preaction I see now that the patch doesn't work. I think it only worked for me because I've set the blog app route to "/" and I was thinking incorrectly that tags would always be under "/tag". See https://github.com/preaction/Statocles/pull/586 for an attempted fix.

If I understand the taxonomy you propose, it's kind of like that already with routes for apps being set in the "conf" object. #586 uses it, but I sense you had an idea behind removing "route" from the blog/list config.

Also, url_for does a lot of things that I don't really understand (https://github.com/mojolicious/mojo/blob/master/lib/Mojolicious/Controller.pm) but I wonder if someone who wants to have "/blog/tag/programming" under "/my-programming-tricks" can accomplish that by modifying their version of lib/Statocles.pm telling Mojolicious to add such a rule, so that url_for rewrites the URL as they wish.