On Wed, Nov 19, 2014 at 1:27 PM, Andrew Beverley <andy@andybev.com> wrote:
On Wed, 2014-11-12 at 10:23 +0100, Sawyer X wrote:
I have two comments left: 1. I don't think API requests should be conflated with regular page rendering. This should be a clear "I send you JSON, I receive JSON" and a clear "I send a request from the browser to render output for the user and expect to receive HTML back". There is one exception in which you might want to make a JSON request return a rendered HTML which you could stick in the page ("template 'parts/box' => {...}, { layout => undef };") but that's something which would then also get serialized and returned back. Imagine an API on the frontend having to account for either JSON or HTML, not knowing how an error would be returned. It could be a JSON structure with the error or an HTML which itself is an error. It's gonna have a bad time. :)
Okay, I think I may be using this wrong. I have the auto-serializer set to "JSON", which from what I can tell, will look at every response, and always attempt to serialize the output as long as it is passed a ref, regardless of the request. So when I'm returning HTML to a HTML request, it will still try and serialize the data if that HTML happens to be in a reference (even if it stringifies).
This used to be true, but recent version changed it and for good cause. Originally serializers would check if it's a reference or not, which is wrong because some serializers can also serialize scalars which aren't references. This meant we're both crippling new serializers we haven't thought of (Dancer2::Serializer::CBOR, for instance) and providing inconsistent behavior to you, the user. Latest version of Dancer2 will *always* call the serializer to deserialize and serialize. If you provide bad input, you'll get an error. If your users send a bad request, it should result in an error as well. While those errors should do the right thing (render an HTML or return a serialized error), you can still hook up to errors, both in the app and the serializer. We still have two additional features we want to implement regarding those (that Mickey Nasriachi and I worked on yesterday): having a default serialized output (for cascading recursive serialization errors) and using Throwable internally.
I am assuming that I should instead set the serializer to "Mutable", which will only try to serialize the appropriate requests.
Mutable (which itself could use a once-over and has associated issues on GH) should be able to handle multiple serializers. Paths which have serializers should be expected to always try to deserialize and always return serialized output.
2. If you found the error unhelpful, we should definitely fix it.
I guess my point was that I couldn't think of any way it could be more helpful, otherwise I would have made a pull request ;-)
Fair enough. :)
Thanks,
All the best! Sawyer.