Fork me on GitHub
#perun
<
2017-02-28
>
martinklepsch05:02:26

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

podviaznikov19:02:27

martinklepsch: interesting. I once built for myself kinda radio based on soundcloud. So everyone who is on the page would listen to the same songs as everyone else. Different from your idea though

martinklepsch19:02:56

Yeah, more thinking of this as some kind of library. I’ve always starred/favorited lots of tracks on SoundCloud/Spotify and I want that information to be preserved no matter the platform that I’m using

martinklepsch07:02:07

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 ?

bhagany13:02:33

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

bhagany13:02:29

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.

bhagany13:02:40

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

bhagany13:02:40

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

martinklepsch13:02:42

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

bhagany13:02:42

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

bhagany13:02:36

there are tasks that don't use it

martinklepsch13:02:01

(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})
does this look about right to you?

martinklepsch13:02:34

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

bhagany13:02:01

yeah, that looks like what I'd expect

martinklepsch13:02:47

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

bhagany13:02:37

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?

martinklepsch13:02:12

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

bhagany13:02:18

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 🙂

martinklepsch13:02:03

haha, that’s both good and bad I guess

bhagany15:02:10

:rendererd -> :rendered

bhagany15:02:44

took me a while!

martinklepsch15:02:32

hm. but then I still get this:

java.lang.ClassNotFoundException: ofe.contentful.Track
which is weird because that namespace should be required transitively

bhagany15:02:57

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

bhagany15:02:13

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

martinklepsch15:02:58

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

martinklepsch15:02:09

(see right after the contentful task)

bhagany15:02:16

okay, I see it

bhagany15:02:22

odd, investigating

bhagany15:02:23

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

bhagany15:02:46

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

martinklepsch15:02:32

@bhagany are you running master?

bhagany15:02:43

no, the atom branch

martinklepsch15:02:36

@bhagany I mean of perun itself, sorry

bhagany15:02:48

oh, sorry, yes

bhagany15:02:56

double checking that

bhagany15:02:37

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

martinklepsch15:02:02

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

bhagany15:02:28

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

martinklepsch15:02:42

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

bhagany16:02:14

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

bhagany16:02:14

okay, getting that error now...

bhagany16:02:26

print-meta is the source of the error

bhagany16:02:54

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

bhagany16:02:17

boot contentful target works

martinklepsch16:02:02

ok, that’s some progress 🙂

bhagany16:02:16

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

martinklepsch16:02:47

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

martinklepsch16:02:58

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

martinklepsch16:02:14

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

martinklepsch16:02:33

wohoo I generated a feed!

bhagany16:02:39

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

martinklepsch16:02:14

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

bhagany16:02:11

I bet it's more general than that

martinklepsch16:02:23

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

bhagany16:02:38

yes, I think so

martinklepsch16:02:01

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

bhagany16:02:55

Because of the atom requirements like uuids and such?

martinklepsch16:02:36

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

martinklepsch16:02:35

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

bhagany16:02:49

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

bhagany16:02:43

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.

bhagany16:02:06

or md5 the url

bhagany16:02:20

just something that's unique and repeatable

bhagany16:02:42

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

bhagany16:02:40

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

martinklepsch16:02:14

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

martinklepsch16:02:02

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