unclear request object being used in example about alternative serializations

[raj-k-singh]

I was going through the restless docs about extending restless.
In the section about handling multiple forms of serialization
around line 470 in the MultiSerializer example,

class MultiSerializer(Serializer):
        def deserialize(self, body):
            # This is Django-specific, but all frameworks can handle GET
            # parameters...
            ct = request.GET.get('format', 'json')
            if ct == 'yaml':
                return yaml.safe_load(body)
            else:
                return json.load(body)

        def serialize(self, data):
            # Again, Django-specific.
            ct = request.GET.get('format', 'json')
            if ct == 'yaml':
                return yaml.dump(body)
            else:
                return json.dumps(body, cls=MoreTypesJSONEncoder)

in line ct = request.GET.get....
Its not clear where the request variable being used is coming from. I experimented a little and realized that neither the serializer instance nor the supplied arguments contain the request instance.

Can you please clarify if I am missing something here - in which case we can just improve the docs around the same.

Also if the request instance is not really present, my ideas around making it available would be as follows

• make the resource instance available as Serializer.resource - so that it can be used as self.resource (I dont recommend this one since it makes too much of the details available to the serializer)
• make the request instance available as Serializer.request - so that it can be used as self.request - but this one can raise thread safety issues.

I would be happy to make the changes and raise PR for you if you would like that

[mission-liao]

Hi,

I'm not a Django-guy, but I think __request__ refers to [HttpRequest](https://docs.djangoproject.com/en/1.8/ref/request-response) in Django.
It's a good synthetic sugar but really confusing for new comers.

[raj-k-singh]

@mission-liao Thanks for the comment
I am not new to django and there clearly is some mistake here - or I am missing something that is not django. It is clear that the request variable is intended to hold the HttpRequest. But quite clearly that variable is being used without being assigned to or being obtained from somewhere.

[raj-k-singh]

There exists a work round for someone to get hold of a request object without it being explicitly passed around - but that involves writing a custom middleware and then making the request available as a thread local variable on the current thread. I believe that would still be overwork - considering that the request is indeed available with the Resource

[vr2262]

I've just been bitten by this as well. I'm using Restless in a Tornado application and I would like to access the URL parameters within the serializer, but the request is not available.

[ross-urban]

This still seems to be an issue. Does anyone have a solution short of writing a custom middleware?

[ElSaico]

The documentation mismatch seems to be a remnant from pre-2.0, when serialization was coupled to Resource and its subclasses.

A stopgap solution (though a bit unwieldy) would be to add request as a parameter to both deserialize and serialize, then override build_error, serialize_list, serialize_detail, deserialize_list and deserialize_detail to pass it as self.request.