Redirecting in a plugin view. #79
Comments
|
maybe a possibility to raise an exception and middleware that will handle it |
|
Right now this does not work as expected, as raising an exception in a plugin raises a TemplateSyntaxError. So no way to do anything. |
|
we could set a variable on the request and the middleware could look for if this variable is present. |
|
This works, but still it would be more convenient if there was the possibility to return a HttpResponse in the plugin, as
Why do we have to return the context anyway, if we can modify the context directly? |
|
The problem is that at the moment when the plugin is rendered we are not anymore in a view but already in render_to_response. This is needed for 3th party app support. We could check if the render function returns a HttpResponse.... and if it does wrap it like described above... would make the api simpler and more intuitive.. |
|
We also could assign the response to the request and then raise an exception... this would eliminate the render to the end problem. |
|
What do you mean by: if we can modify the context directly? |
|
I did not take a look at the django-cms code, but the context variable is passed to the render method, that's why we could just update it and not return it. That way, the return value of render() would be reserved for a HttpResponse. But I agree that we shouldn't change the behaviour, so a check isinstance(retval, HttpResponse) might be an option. |
|
Well, maybe we could add an (optional) process(request) method to plugins that does whatever it needs to do – for instance, validate a form – and is called before anything is rendered. That method could return a HttpResponse object or nothing at all or… well, just thinking along. In any case, it would be really nice if you could redirect the browser after form submissions to prevent double submissions (standard behaviour for many web apps). |
|
if we would have a second method for processing the request you would need to process it twice for rendering the form in the render method. There is also the question of when to process this as the plugin_media is optional. Anyway I would say that the render method is enough. The question is should a HttpResponse be returned and then the calling function raise a Exception and the middleware handles it and returns the appropriate response or should render raise an Exception itself. I think returning HttpResponse is more django-like |
|
+1 on returning a HttpResponse instance directly. |
|
I don't think this behavior is desirable at all. Plugins are for usability. They should not implement any sort of behavioral logic but should be easy to preview in the admin and understand from a users perspective. We use CMS because content maintainers are not techies. You cannot preview a redirect. People who want redirects should implement a view or some middleware. I don't see the justification why this is excluded. |
|
+1 on returning a HttpResponse |
|
-1 on this issue. This is not what plugins are there for. |
|
+1 |
|
I'd generally second ojii. I think DjangoCMS needs a BD(FL?), otherwise we will be stuck on issues like this one :) |
|
okay here's the BDFL decision on it: (make apphooks for this kind of stuff) |
|
A workaround here: |
|
+1 on @motiejus 's snippet. Sometimes (like after a form POST processing) you need to (or even worse, should) redirect. |
|
This does not work any more, because error is raised during rendering of responce, i.e. here: https://github.com/django/django/blob/master/django/core/handlers/base.py#L157 And it is not wrapped with try...except, and no middleware exception handler is called 😞 |
Please add the possibility to redirect an user in a plugin view. Sometimes it's preferred to control a flow on the server side, instead of using AJAX.
The text was updated successfully, but these errors were encountered: