@roelofw I had a very quick look at code. One comment, I don't think wrapping the pmap calls in a future is necessary. It just adds complexity.

The pmap will parallelise all the calls over a thread pool and handle the semi-laziness for you, blocking as required when it's realised by the merge.

Couple of style things - it's common practice to not leave trailing close parens ) on a separate line but have them close off the expression on the same line e.g.

art-objects (-> response
                        :body
                        :levels
                        )

art-objects (-> response
                        :body
                        :levels)

Except slack has messed up formatting as the :body and :levels should line up under response

I might think about names of functions too. Maybe read-data-painting is now better named format-painting-data for example.

But generally you've learned a lot! Well done.

Thanks for the feedback , @agile_geek

I think I have to do things otherwise. On the first page I only need the image of a painting

and on a second page that I still have to build. You will see the same image with a place where the details are schown.

So Im thinking to delete the do-all function and make the call to the api in the home routers file

Can I still use the pmap there so things are "downloaded" in parallel.

When you then click on a image , then the details are pulled out of the api with the read-data-painting

Because the map is not a variable , I cannot reuse it on the to build detail page

You can use pmap to parallelise calls for different urls (i.e. different painting ids) whereever

Not sure I understand the bit about the build detail page? If the idea is to render a list of paintings and then click on a link to render the detail of a specific painting, pass the key of the painting (plus any other variables) in the query sting of the href on the link. Then destructure the query params in the function that handles that route.

yes. in fact for the detail page we have already desctruced it with read-data-painting

Yeah but once you've returned a response you server side data is gone. Unless you store it in a session. So if you render the link to the detail with the data you need in the query string you don't need to store session data

Remember you may have thousands (hopefully) of users at same time so one global variable storing id's of paintings might work in this site but if everyone's view was different it wouldn't

Try and make your server stateless.

yep, that why I thought of first only download the numbers and the images and shown them

When I user clicks on a image then there will be another call to the api which pulls out the details and shown it

What happens if someone bookmarks the details page and then goes there as the first page after a server restart?

so nothing gets "stored" anywhere

a nice one. I have to think about that

If you render the images with an anchor with an href that includes all the information you need (i.e. id's) then you can catch this info in the function dealing with the route, extract the id of the painting and do the detail api lookup for that painting before rendering the detail page. Nothing is stored server side.

oke, in fact the same as I schould do when someone wants to see a detail page

but first some more 4clojure and standford challenges

and find a better layout which also works on mobile and so on. As you can see im not a front-end developer or a designer , @agile_geek

neither am i!

join the club. Problems I have with most of the templates I found is that all paintings/photo's have the same dimensions. With me there are some landscape and some not. And there are not of equal width and height