<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 1:27 PM, Andrew Beverley <span dir="ltr"><<a href="mailto:andy@andybev.com" target="_blank">andy@andybev.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2014-11-12 at 10:23 +0100, Sawyer X wrote:<br>
> I have two comments left:<br>
> 1. I don't think API requests should be conflated with regular page<br>
> rendering. This should be a clear "I send you JSON, I receive JSON"<br>
> and a clear "I send a request from the browser to render output for<br>
> the user and expect to receive HTML back". There is one exception in<br>
> which you might want to make a JSON request return a rendered HTML<br>
> which you could stick in the page ("template 'parts/box' => {...},<br>
> { layout => undef };") but that's something which would then also get<br>
> serialized and returned back. Imagine an API on the frontend having to<br>
> account for either JSON or HTML, not knowing how an error would be<br>
> returned. It could be a JSON structure with the error or an HTML which<br>
> itself is an error. It's gonna have a bad time. :)<br>
<br>
</span>Okay, I think I may be using this wrong. I have the auto-serializer set<br>
to "JSON", which from what I can tell, will look at every response, and<br>
always attempt to serialize the output as long as it is passed a ref,<br>
regardless of the request. So when I'm returning HTML to a HTML request,<br>
it will still try and serialize the data if that HTML happens to be in a<br>
reference (even if it stringifies).<br></blockquote><div><br></div><div>This used to be true, but recent version changed it and for good cause.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am assuming that I should instead set the serializer to "Mutable",<br>
which will only try to serialize the appropriate requests.<br></blockquote><div><br></div><div>Mutable (which itself could use a once-over and has associated issues on GH) should be able to handle multiple serializers.</div><div><br></div><div>Paths which have serializers should be expected to always try to deserialize and always return serialized output.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 2. If you found the error unhelpful, we should definitely fix it.<br>
<br>
</span>I guess my point was that I couldn't think of any way it could be more<br>
helpful, otherwise I would have made a pull request ;-)<br></blockquote><div><br></div><div>Fair enough. :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br></blockquote><div><br></div><div>All the best!</div><div>Sawyer.</div></div></div></div>