Clojurians Log v2

@podviaznikov idea basically stems from having one track of each kind/artist, not sure how practical that will be but ¯\(ツ)/¯

Can’t figure out how to use content-task properly It’s not clear to me what the individual functions need to return — some schema type checks would go a long way. Maybe add some truss assertions https://github.com/ptaoussanis/truss ?

@martinklepsch unfortunately the returns for most of the functions that content-task takes are too open for an assertion to help you out very much. The docstring for content-task is a bit terse though, and I can expand it. Briefly though, for your use-case, :render-form-fn returns a form that will be called in a pod (via boot/with-call-in), and :paths-fn should probably be the same one you used for render-task.

The namespace-qualified function that render-form-fn returns is responsible for rendering a single file. It should return a map of metadata that will get set on the file, and the :rendered key of that map should be a string that contains the rendering result.

You can ignore :passthru-fn for your use-case

If an example would be easier to follow, there are several in perun.clj. I think atom-feed is the closest to your use-case: https://github.com/hashobject/perun/blob/master/src/io/perun.clj#L1090

@bhagany they might be open but still at some point some other piece expects something at :rendered etc

:rendered isn't expected really, it's just handled specially

there are tasks that don't use it

(perun/content-task {:task-name "contentful"
                       :render-form-fn (fn [data] `(ofe.static/render-track-page* ~data))
                       :paths-fn ofe/contentful-paths
                       :tracer :ofe.contentful/contentful
                       :pod perun/render-pod})

render-track-page* assocs the rendererd html (as string) to the :rendered key

yeah, that looks like what I'd expect

When I run this and then print-meta there are no entries for the pages that I just rendered

I'd have to do some print debugging to get to the bottom of that... would it work if I run it locally, or would I need contentful credentials of some sort?

It’s early in the morning where you are — maybe bring your kids to school and ping later if/when you find time?

@bhagany it should work, creds are public and hardcoded: https://github.com/martinklepsch/one-of-each/tree/atom

yeah, I'm about to leave 🙂 finding time will be easy though, as my employment situation is currently complicated, in a way that gives me a lot of free time 🙂

haha, that’s both good and bad I guess

talk soon

@martinklepsch it's just a typo 🙂 https://github.com/martinklepsch/one-of-each/blob/atom/src/cljs/ofe/static.clj#L56

:rendererd -> :rendered

oh my!

took me a while!

hm. but then I still get this:

java.lang.ClassNotFoundException: ofe.contentful.Track

ah, that's the same issue as the bug we discussed last week

I'll try to get a final fix in for that today

it is but I’m explicitly requiring that ns in the pod in build.boot

oh... hrm

(see right after the contentful task)

okay, I see it

odd, investigating

... I can't seem to reproduce that error, but I did modify things a bit to make it run, maybe I'm not hitting the right code path?

contentful is writing 4 files, and then atom-feed is erroring because of missing authors

@bhagany are you running master?

no, the atom branch

@bhagany I mean of perun itself, sorry

oh, sorry, yes

double checking that

I was behind a commit or two, but I'm up to date now, and getting the same result on one-of-each

the only change you made is fix the :rendered typo I guess?

I also changed some stuff in build.boot, just to get the contentful task to run

what’s the exact CLI invocation you use? I do boot contentful perun/print-meta target

ah, I was running boot dev, I'll try yours

okay, getting that error now...

ah, I see

print-meta is the source of the error

I think it's trying to print a Track, but it's not loaded in the print-meta pod

boot contentful target works

ok, that’s some progress 🙂

that's probably fixable in the same manner as the bug from last week

for print meta I did the same thing as for render, just require it in the pod

for the atom task that doesn’t work because pod isn’t globally defined

Really the simplest thing at this point is just turning them into ordinary maps 🙂

wohoo I generated a feed!

the fix I'm working on might work for atom-feed as well... but maybe maps aren't a bad idea either 🙂

one bug report: when I set :out-dir in for the atom-feed task to an empty string it ends up being an absolute path

ah, noted

I bet it's more general than that

this does the trick but I guess empty string should be fine too? ”.”

yes, I think so

Ok think with my weird setup I might have to implement the rss feed markup seperately

Because of the atom requirements like uuids and such?

that + the fact that the :content keys are already full html pages

shouldn’t be too hard with another content-task though I guess

full html pages should be okay - are they being picked up by a later render task or something?

for atom, I think the biggest difficulty is in having a unique, stable id for each entry. It doesn't technically have to be a uuid, though. For instance, if you know the content won't change, you could md5 it or something, and use that.

or md5 the url

just something that's unique and repeatable

(this is assuming you can't just set some metadata field in contentful that you can access, which would be easiest)

oh, it looks like you already get a "uuid" back... I don't think I understand where the difficulty is

Oh yeah, I was using a validator, maybe most RSS readers don’t care to much about what it says

will try what the feed looks like in a reader with the default impl