This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-30
Channels
- # adventofcode (11)
- # beginners (155)
- # boot (627)
- # cider (64)
- # cljs-dev (110)
- # cljsrn (36)
- # clojure (290)
- # clojure-austin (21)
- # clojure-russia (2)
- # clojure-spec (2)
- # clojure-uk (21)
- # clojurescript (81)
- # code-reviews (2)
- # core-async (33)
- # cursive (6)
- # datomic (9)
- # emacs (1)
- # hoplon (472)
- # instaparse (1)
- # lein-figwheel (4)
- # luminus (9)
- # om (2)
- # protorepl (10)
- # re-frame (10)
- # reagent (48)
- # schema (2)
- # sql (5)
- # untangled (17)
- # vim (1)
- # yada (108)
@malcolmsparks care to explain how asciidoc is compared to orgmode?
I'm having some troubles serving resources from the classpath. I tried new-classpath-resource
as discussed here: https://clojurians-log.clojureverse.org/yada/2016-02-11.html but a request to /
returns a 405.
["" (yada/yada (cpr/new-classpath-resource "public"
{:index-files ["index.html"]}))]
@martinklepsch does "public/" work? Nvm, misread the source
There may be a bug in the code, just based on a cursory read. Not entirely sure how path-info
works, but we first remove #"^/"
(as in the /
request...) and then only load the index file if the path ends in /
.
https://github.com/juxt/yada/blob/9efb80c3ebadf2289abf6beaf9fed38fcb690b32/src/yada/resources/classpath_resource.clj#L39 this is the line that needs changing.
this has been reported before, Jannis Pohlmann contributed this code
background do path-info here: https://juxt.pro/yada/manual/index.html#sub-resources
I read the subresource docs but didn’t see my issue.
Somehow the issue solved itself
hmm. don't like issues that solve themselves...
Likewise
there must be something odd going on
I’ll ping back if it comes up again. Might have been related to my routes as well
I'm not completely happy with the way things are with classpath resources right now. Bidi has this thing called ResourcesMaybe that allows the pattern matching to continue if a resource isn't found
but bidi's ResourceMaybe isn't as complete as a yada resource
ideally it should be possible to get the best of both worlds, but needs some thought. The separation of bidi and yada is quite a key principle for me
btw. there's lots in yada that I'm not happy with, and I'm slowly improving yada but being much more careful to preserve compatibility for existing users
@vinnyataide really needs a blog article, but in summary they are similar at the back-end and both can produce excellent configurable PDF output, xrefs, auto-numbering, toc, etc.
that's if you decide to go with TeX (rather than FOP) for the backend, which I believe it still unmatched in various areas (like hyphenation rules)
At the front-end, they are different obviously - orgmode's biggest disadvantage, imo, is that it's informally defined, org really relies on Emacs as an editor (although you can edit it with something else), and it's a bit of a black art
The key benefit of asciidoc is that it has an extra tier in the pipeline - DocBook XML . This makes it very configurable - you can use XSLT to customize any existing behaviour - XSLT is a wonderful thing, very under appreciated
Asciidoctorj does a good job of rendering to HTML natively (and dynamically if needed, we do that on our http://juxt.pro website)
But also asciidoctorj does a good job of turning AsciiDoc into DocBook XML (I use DocBook XML 5 because it's all XML, having shed the last vestiges of its SGML history)
DocBook is very mature, has a bigger community than Emacs/org-mode
O'Reilly and other publishers use it too, so it's well trodden
AsciiDoc and DocBook are isomorphic, that's the point - so you get the power of DocBook without needing to hand-author XML, which was the real pain with DocBook authoring
Best of both worlds
For those who aren't familiar with DocBook - http://docbook.org/ -it's been around forever and came out of the SGML world for publishing technical books - it has great support for the features you need when writing technical documentation
No idea what any of this has to do with yada, apologies if you're not interested in this stuff 🙂
But if anyone is interested, the PDF publishing toolchain is in the yada repo under doc/ (or atleast will be soon when I've pushed to github)
Now when doing curl localhost:4000
I get the 405
The problem with new-classpath-resource is that when there is no 'path-info' (the part of the path that remains after the rule has been matched), then the sub-resource logic is not called - you just get the top-level :methods decl which is empty, hence it's a 405 (no such method)
this has always been a problem with this code
the workaround is to place a redirect at "" which targets some index file which can be served by new-classpath-resource
there's yada/redirect, or bidi has a redirect capability, or just a ring thing
new-classpath-resource can't do redirecting to index files for you, at least not at the root
or we can just fix new-classpath-resource now to do the right thing
which would be to redirect to the value of :index-files by default
but I suggest the workaround for now because currently I'm trying to get quite a big amount of holiday yada work pushed
I don't think an empty path is valid, one will always be appended to a URL by your browser or user-agent
GET / HTTP/1.1
you obviously cannot have the following HTTP request
GET HTTP/1.1
that would violate the HTTP standard
So what's going on here is that there's a / matching
the "" of your new-classpath-resource rule matches, and "/" becomes the path-info
that means we avoid the bug where new-classpath-resource have 0 methods defined for the case where there is no path-info, and duly creates a sub-resource for handling the path-info of "/"
You can group the first three routes together
["/" [ [] [] [] ]]
remember, when you do this, you need a vector-of-vectors on the right-hand-side
it's not like pedestal where you can have ["/" [] [] []]
that's really the main thing to remember with bidi - in the right-hand-position it's a handler, or vector-of-vectors
but I think you've found a nice workaround for the new-classpath-resource issue - nice!
Thanks Malcolm, that’s helpful. I’ll try to internalize "the right hand should be either a handler or a vector of vectors”.
@martinklepsch good luck - shout if you need more help
In the Swagger example given here https://juxt.pro/yada/manual/index.html#hello-swagger the hello-routes
are available at /
and under /api/
— is there a practical reason for this?
Or are the routes under /api
different in some way?
No, you could just use the /api ones
I see your point, it's a bit confusing
I’m new to Swagger so it might be more confusing to people like me than to people more familiar with Swagger
No, the docs definitely need improving here. If you want Swagger, use it, otherwise avoid it
I don’t know if I want it but playing around with the integration won’t hurt 🙂
integration?
didn't quite understand you 😉
Well, the Swagger support or integration or whatever you want to call it 🙂
the swagger integration needs a bit of work -it's hard because swagger doesn't always follow http and does its own thing - it's a bit of a tension between compile-time declarative and run-time dynamic (which REST prefers)
e.g. if you compute your 'produces' variants at runtime, how can swagger descriptions be produced ahead of time?
ring-swagger gets round this by firing tracer bullets into your resources - I'm not sure I want to do that - it's a bit of a hack - you don't want to launch the missiles when you think you're only creating a Swagger description
these days, APIs actually do pretty severe things, perhaps some even launch missiles who knows
(i'm personally not a fan of people launching missiles at other people)
I'm currently finishing work splitting yada into a minimally small working core and a set of extensions - users shouldn't notice any difference but it paves the way to add non-standard extensions and contribute things to yada that normally wouldn't be considered core
extensions include json, transit, json-html, swagger, multipart
it will also allow usage of yada where dependency-hell is an issue
the minimal yada library will only have 5-6 dependencies
have you @malcolmsparks considered using the HAL spec? should suit better for REST-style api-docs. There is also a nice ui for that (https://github.com/mikekelly/hal-browser)
@ikitommi Hi Tommi - I have never heard of HAL before - thanks for the tip!
yes, this looks nice: http://haltalk.herokuapp.com/explorer/browser.html#/
@malcolmsparks thank you sir, I really appreciate the explanation
@malcolmsparks @martinklepsch Hey, sorry the code I contributed causes problems. Shall I try to fix new-classpath-resource
to make up for it? I just need to understand the problem first and the behaviour we want.
It sounds like @martinklepsch’s problem was that “localhost:4000” lead to an empty path info, which then didn’t fall back to :index-files
(the if
conditional in new-classpath-resource
isn’t very good, I admit that).
@jannis Hi there - no complaints really, thanks for the contribution - it's been useful. The only issue is that people expect different behaviour when it is called without a path-info (e.g. the 'root'). They expect a redirect to :index-files but instead get a 405 (because there's :methods {}
in the parent resource)
Would a check for an empty path info -> then fall back to :index-files
be enough or is that only a partial fix? (Or no fix at all)
A simple redirect would work {:methods {:get (fn [ctx] (throw (ex-info {:status 303 :headers {"location" (-> ctx :request :uri (str index-files))}})}}
@jannis yes, that would work - only if there is no path-info there is no sub-resource called, so the resource has to work on its own
so you can't check for an empty path-info, yada does that already - if there is a non-empty path-info it will create a subresource
Do I understand right that the sub-resource can’t work because sub-resources only work if there’s a path-info?
I think it might be possible to implement the use-cases needing subresources (file directories, etc.) using dynamic properties functions - the subresources thing adds additional complexity to yada, I don't think it's warranted
@martinklepsch yes - that's how it's implemented
sub-resources were a bit of an experiment to make it possible for yada to serve directories of files (at first)
not sure they work that well in practice
path-info, however, is very useful, and could form part of a better approach
Essentially instead of :methods {}
. There would need to be an implementation that returns index-file
?
well, there needs to be an entry in :methods {}
, i.e. :methods {:get ...}
and I think a 30x redirect is probably what is needed here
Hmm. I don’t understand the logic around subresources yet, so I’m not sure where the {:methods {:get …}}
redirect would be placed.
right, that’s what I meant
line 35
the problem is that if the path-info is empty ("") then the function in :sub-resources isn't called
the idea of sub-resources is having a parent resource that looks after a whole collection of resources, each 'sub-resource' is targetted with a different path-info - subresources are dynamically created for each request
@jannis - yues
Why would a redirect be better than the actual response? If I understand correctly a redirect would change the URL to contain the path displayed in e.g. a URL bar to index-file
. That may not be the desired (?)
I think you've added an empty one to get past the schema check 🙂