Call POST internally

[encode]

Call POST internally

[tomchristie]

Interesting...

Having the create a mock request to use the views internally is pretty icky.
I've been planning to rewire how the model mixins and model views stick together, and I think it'd also solve the problem of how to access views internally. Would be great to get your feedback.

So the various model mixins, rather than defining the .get(), .put(), .post() method handlers directly, would instead define the .read(), .update(), .create() actions. Eg: http://pastebin.com/8bFQJGwc (It'd also be possible to then move them all into a single ModelMixin class for the sake of brevity)
The model views would then define the .get(), .put(), .post() method handlers, mapping them to the correct actions. Eg: http://pastebin.com/pv0qMaEy. The model views would be the place that self.CONTENT gets accessed if required, and handle any request/response specific stuff (eg returning redirects to created model instances)

In which case your code would look like:

@render_to('monitoring_added.html')
def add_monitoring(request, entity_id):
    response = MonitoringApi().create({'entity_id': ..., 'user_id': ...}
    return {'content': response.content}

(Or possibly...)

@render_to('monitoring_added.html')
def add_monitoring(request, entity_id):
    api = MonitoringApi()
    response = api.fiter_response(api.create({'entity_id': ..., 'user_id': ...}))
    return {'content': response.content}

Does this make sense, and does it solve what you're trying to do more nicely?

[dbrgn]

Hm, this could be a possibility. But there could be a problem with the authentication. In some cases, the authentication needs the csrf token, which is contained in the request. By passing a request object on to a "fake request handler", there should be no problem. But if the create/update methods accept the direct values instead of the request objects, authentication would be circumvented and would have to be duplicated.

Or maybe I didn't fully understand your answer :)

[dbrgn]

But still, I think the approach using a request and modifying it should work in theory. Do you know what the problem could be with the code in the issue description?

[tomchristie]

Yeah, so you're modifying request.POST, which isn't actually the underlying request content.
(Rather a property which reads from the stream, parses it, stores the result and then returns it.)

If you were instead modifying request._stream (or .stream I don't remember right now), and setting it to the url-encodeded/multipart encoded form data then everything would work fine - REST framework's FormParser/MultiPartParser would read the stream and decode it into the form dictionary. As it is they'll look at the stream and find it empty.

It'd be possible to modify REST framework to deal with your use case, but there's a bit of fiddly-ness involved.
Eg at the moment FormParser and MultiPartParser handle parsing arbitrary streams.

[dbrgn]

Ok, thanks for your answer. I think that would be a great feature, but for now I'll just send a HTTP request to my own server (even though that's pretty messy :)).

[tomchristie]

The easiest hack way to make it work would prob be to use a custom FormParser and MultiPartParser on each request that subclass the existing parsers, but override the .parse() method like so:

class CustomFormParser(FormParser)
    def parse(self, stream):
        return (self.view.request.POST, self.view.request.FILES)

[tomchristie]

Note that this is now being worked on, in the experimental branch...

https://groups.google.com/forum/#!topic/django-rest-framework/JJJH28NoPSE

[dbrgn]

Thanks for the note.

[tomchristie]

Example using REST framework 2.0.

https://github.com/tomchristie/django-rest-framework/blob/restframework2/rest_framework/tests/renderers.py#L114

(No idea if this'd work fine in 0.4, but I suppose so.)