Clojurians Log v2

requesting a sanity check on this - I have some tagged articles. I would like to generate a page per tag, and list the appropriate articles per tag. This is almost what collection does, but the issue in this case is that each article can have multiple tags, and will therefore appear on multiple tag pages. Since collection only exposes a predicate for group-by, I don’t see a way to achieve this behavior, other than manually specifying a collection per tag in my build task.

I copied and modified collection to accept a function that does all of the grouping instead of a predicate for group-by, which is pretty much the only path I see to get automatically-generated pages per tag without knowing the tags ahead of time. I question this approach, because it feels like perun doesn’t want me to do things like this.

In particular, I end up copying private functions over to my own code, which is a warning flag for me

(in this case, I needed render-in-pod, wrap-pool, and commit)

Can anyone set me straight?

it’s an interesting use case. It does seems that right now it’s hard to do. I usually do specify all my collections manually per one file. And it does seems to be problematic if you have a lot of tags and the list is not fixed

I’m now even doubting if group-by should be an option of collection task. Maybe collection should always map to one file and grouping and other cases like yours should be solved using other primitive tasks. Or maybe we should continue with what we have right now and make collection more flexible

one way for you do solve problem for now can be writing something like <https://github.com/hashobject/perun/blob/master/src/io/perun.clj#L298> sitemap task. What you want to do is to create a task that will create new files in the fileset for each tag (and files would have some specific key you can use to filter those created by you later). Than you would defined render task and would apply it only to the files you’ve created. Does such idea make sense?

This is basically what my modification of collection does. It just doesn’t feel “right” to me, because I end up having to copy and paste a bunch of private functions from perun.clj. Because of this, it feels like perun doesn’t want me to define these kinds of tasks. Or is there another reason that functions like render-in-pod are private?

I could go either way on the group-by option in collection. I was surprised that it was there, and maybe it feels a bit complected, but I don’t mind it so much.

I think maybe there could be a task that takes a function that returns a map of {path-in-fileset contents} and these will be written into the fileset then by the task. Kind of a mix of the render and collection tasks sort of? Hope that makes sense.

@bhagany I think at this point it would make sense to stress that the API is not considered stable and if you have any interesting ideas we should totally discuss them.

(Maybe this discussion is better done in a Github issue though. Just so that it isn't lost later on.)

heh, don’t worry, I’m under no illusions about the stability of perun’s API. That’s part of the reason I picked it 🙂

My question, if I can rephrase it again is this - am I, as just a consumer of perun’s API, supposed to write tasks that add to the fileset? Or is it perun’s intent that it manages the fileset, while consumers write tasks that modify the metadata?

One thing I've been thinking about as well is using Rum to render HTML and potentially do something interesting with server side rendered stuff in that context

@bhagany I think perun's tasks should handle most use-cases. When it doesn't you need to do your own thing. Where the border between these two sides is isn't clear yet I'd say. Also consumers don't really modify the metadata directly in most cases but use tasks that enrich it & are specialized (permalink, etc.).

ah, yes, I think I mean the same thing by “modify” as you mean by “enrich"

I will think a bit, and see if I can come up with a proposal that is interesting enough. I’ll use github for that.

Thanks for your patience with me 🙂

Thanks for your patience with this whole thing as well 😄 I think it's quite hard still but there are some rough diamonds somewhere 🙂

sure! the whole idea has a lot of promise, and finding those diamonds is fun.

appreciate that attitude 🙂