[dancer-users] Incorrect attempts to serialize HTML

[Sawyer X]

On Wed, Nov 19, 2014 at 1:27 PM, Andrew Beverley <andy at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20141123/5c0cefe1/attachment.html>