Fork me on GitHub

How to make an exception handler that will allow me to make a custom error page? Specifically I'd like to generate json document in case of any error.


@jsyrjala search the doc for 'status responses', that's the feature you need


is it by design that header values cannot be coerced? the use case is e.g. an X-Auth-Token that should become a UUID.


declaring the resource works, but when performing a request to it, it returns a 400 {:error {\"x-auth-token\" (not (instance? java.util.UUID a-java.lang.String))}}


I've just submitted a bug report but I'm also available here for next couple of hours to help with reproducing the issue


@stijn no, not by design. Would be a nice feature


@mishok13 thanks, was actuwlly going to ask you did that, yesterday was #xt16 and I was very busy!


I'm quite perplexed as to what's going on there


seems that exception is raised initially by yada.representation/select-best-representation due to config mismatch but then yada.handler/handle-request-with-maybe-subresources calls that same function again leading to missing proper exception info


@mishok13 background context is that when there is an error, yada renegotiates the charset. Say your client can parse UTF-8 and Shift_JIS, but your resource can only produce Shift_JIS, but there's any error - do you want that error to be returned in Shift_JIS or UTF-8? I assume you'd want it in UTF-8, especially if there's an English error message. That's why yada renegotiates. Because the error, in this case, is actually a yada internal error, it's going a bit crazy. I think the best thing for me to do is to fix the original error in this case. We still have this issue where yada should distinguish betweeen application and its own internal errors, but that's something I'm mulling over how to do


I'm going to attempt a fix now and release an update


one solution (or hack, depending on your point of view) could be to optionally pre-set a charset for error responses


having said that, i don’t think there’s any webserver out there that actually negotiates charset for error pages 🙂


I'd argue that being somewhat more lenient is a better route, especially given that the spec clearly allows that: > If an Accept-Charset header is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.


the bug is an oversight on my part, I'll definitely fix it


I’m upgrading from 1.1.31 -> 1.1.37, and I’m running into a small issue with defining my own mime types. I’d like to provide a method for process-request-body for my mime type, but I don’t need any special functionality. Other process-request-body methods just call default-process-request-body, but this function is private. I can obviously work around this, but is there a reason for it to be private that I’m not seeing?


heh, my copy and paste workaround isn’t going well either, because default-process-request-body calls other fns that are also private


(again, workaroundable, but still)


alright. would you like another 1-char pull request from me?


no, I've done it -try 1.1.38


wow, fast! thanks!


but if you spot any more, just fix and lein install, then PR me


will do, thank you


everything’s working fine for me under 1.1.38


I'm learning yada and I have a question


when using yada with bidi, do we lose the bidirectional nature of bidi?


how do you generate urls?


do you pass it the entire resource?


Hi @ericnormand - welcome to the channel!


In yada, you can use bidi just like normal. You can place yada resources in the same place you'd put Ring handlers, and use bidi's tag function to tag them. You can then use bidi's path-for function to create URLs to those resources, using the tag as the first parameter


But it doesn't stop there...


yada resources can have an :id entry, usually with a keyword value. That can be used in bidi's path-for function too.


bidi has a vhosts feature now, whereby you specify the scheme/host/port as well as the routes - this allows bidi to create full URIs, which are often useful when doing complete HTTP because some parts of the spec. ask for absolute URLs (Location headers, for instance).


If you use vhosts (if you don't' know the name of the host you'll be deploying to you can use a wildcard), then yada provides convenient access via its functions in yada.context, which are also accessible via yada.yada - it's recommended to require yada.yada to bring in yada's 'public' parts.


One such function is url-for, to get the full URL of the resource you want to target.


So, for example, suppose you had the following resource:


(yada.yada/resource {:id :foo :methods {:get {:response (fn [_] "hello")}}})


You can form a URI to it with (yada.yada/url-for ctx :foo)


ctx is yada's request context and its' passed to every callback so you'll always have access to it


Since ctx contains the request information, it's also possible to calculate the relative path to a resource, with yada.yada/href-for


And there's yada.yada/host-for, path-for, and scheme-for...


Whether you want an absolute URI or relative one depends on what you're doing. If you're generating hypermedia links in JSON request bodies, I'd recommend you use absolute URLs (`url-for`), but if you're generating an HTML form, href-for will be fine.


Finally, all these methods take options, so you can specify :route-params and query-params, which are often needed to generate the full URL.


So in answer to your question, you pass it the :id of the resource, not the entire resource.


If you want to target a particular resource, give it an id - and I recommend you use a (namespaced) keyword for the value.


In my projects I tend to use a single well-known namespace (rather than the ::keyword syntax), so that link-generation survives any refactoring I might do