i am currently trying to return one html page from my django rest framework setup:
#action(detail=True)
#renderer_classes((TemplateHTMLRenderer,))
def confirmation(self, request, *args, **kwargs):
user = self.get_object()
print(request.accepted_renderer) -> BrowsableAPIRenderer | WHY ?
// do some business logic
return Response({'user': user}, template_name='confirmation.html')
But browser prints error:
Object of type 'User' is not JSON serializable
So my question is, why does DRF use BrowsableAPIRenderer when i specified TemplateHTMLRenderer?
Can anybody help me out?
TemplateHTMLRenderer is very poorly documented, so i had to ask this question..
Thanks and Greetings!
This seems the renderer_classes decorator is not working properly with CBV. Anyway, I found one workaround/DRF way to do it.
Override the get_renderers() method
class Foo(viewsets.ModelViewSet):
# your code
def get_renderers(self):
if self.action == 'confirmation':
return [TemplateHTMLRenderer()]
else:
return super().get_renderers()
#action(detail=True)
def confirmation(self, request, *args, **kwargs):
user = self.get_object()
return Response({'user': user}, template_name='confirmation.html')
Related
I have found this snippet in the django codebase:
# Add support for browsers which only accept GET and POST for now.
def post(self, request, *args, **kwargs):
return self.delete(request, *args, **kwargs)
What does this mean? Do browsers delete resources with GET / POST requests? Why? Can somebody provide a rationale / history / link for why this might be so?
It's for django.views.generic.edit.DeleteView. Your code is from DeletionMixin, and DeleteView inherit this mixin for delete object.
here's self.delete() code
def delete(self, request, *args, **kwargs):
"""
Call the delete() method on the fetched object and then redirect to the
success URL.
"""
self.object = self.get_object()
success_url = self.get_success_url()
self.object.delete()
return HttpResponseRedirect(success_url)
You can check about DeleteView in docs (here).
Basically, DeleteView receive both get and post for deleting object. That's why
I'm new to Django. I've worked through some tutorials, written some models, views, forms etc. but I don't understand how they can be tested since either nothing is returned, or whatever is returned is so tightly bound it doesn't make sense in terms of the test.
For example here are two view classes:
class ListBlogPostView(ListView):
model = BlogPost
template_name = 'app/blogpost_list.html'
class CreateBlogPostView(CreateView):
model = BlogPost
template_name = 'app/blogpost_edit.html'
form_class = BlogPostForm
def get_success_url(self):
return reverse('blogpost-list')
def get_context_data(self, **kwargs):
context = super(CreateBlogPostView, self).get_context_data(**kwargs)
context['action'] = reverse('blogpost-new')
return context
The first, ListBlogPostView, doesn't return anything. How can I ever check that this is working correctly?
The second has a couple of functions but their return values are not things I can test with an assert
How could I ever use a TDD approach to Django?
I'm used to using nunit and MS 'unit' tests in Visual Studio, mocking etc
Actually, Django's generic class-based views are not called generic for no reason.
You can view the source of the both ListView and CreateView.
The ListView has a GET method handler:
class BaseListView(MultipleObjectMixin, View):
"""A base view for displaying a list of objects."""
def get(self, request, *args, **kwargs):
self.object_list = self.get_queryset()
allow_empty = self.get_allow_empty()
if not allow_empty:
# ...
context = self.get_context_data()
return self.render_to_response(context)
Which returns a valid Django response and can be tested in tests.py.
If you look at the CreateView, it inherits from BaseCreateView (just like ListView inherits from BaseListView):
class BaseCreateView(ModelFormMixin, ProcessFormView):
"""
Base view for creating an new object instance.
Using this base class requires subclassing to provide a response mixin.
"""
def get(self, request, *args, **kwargs):
# ...
def post(self, request, *args, **kwargs):
# ...
Which also inherits from ProcessFormView:
class ProcessFormView(View):
"""Render a form on GET and processes it on POST."""
def get(self, request, *args, **kwargs):
"""Handle GET requests: instantiate a blank version of the form."""
return self.render_to_response(self.get_context_data())
def post(self, request, *args, **kwargs):
"""
Handle POST requests: instantiate a form instance with the passed
POST variables and then check if it's valid.
"""
form = self.get_form()
if form.is_valid():
return self.form_valid(form)
else:
return self.form_invalid(form)
The GET request will result in a valid response. As you see, the POST method handler here returns either self.form_valid(form) or self.form_invalid(form) depending on the form status.
You can see the source of these two methods in ViewMixin:
def form_valid(self, form):
"""If the form is valid, redirect to the supplied URL."""
return HttpResponseRedirect(self.get_success_url())
def form_invalid(self, form):
"""If the form is invalid, render the invalid form."""
return self.render_to_response(self.get_context_data(form=form))
Both of these methods return a valid testable Django responses.
In conclusion, both of your ListBlogPostView and CreateBlogPostView can be directly tested in tests.py. You just need to have a more detailed look at the implementation of Django's generic views. The power of open-source!
Testing view unlike function most of the time will not have a return value. The way that I go about doing it is to assert the html response.
So for the ListBlogPostView it depends on what is in the blogpost_list.html template.
A general view test should look like this:
class ListBlogPostViewTest(TestCase):
def test_blogpost_list_view(self):
response = self.client.get(reverse('blogpost-list'))
html = response.content.decode('utf8')
self.assertTrue(html.startswith('<html>'))
self.assertIn('<title>BlogPost lists</title>', html)
self.assertTrue(html.endswith('</html>'))
For view that have context you can actually check if it is being retrieved and passed correctly to view.
blogPost = BlogPost.object.get(id=1)
self.assertEqual(response.context['blogPost'].name, blogPost.name)
How could I ever use a TDD approach to Django?
As for TDD, you just have to test the html view first before creating it. It really depend on how detail you like to test and find the balance for it. I prefer to test mainly on the context being set and important html element is in the view.
You can still surely test lot of parameters -
status code on get and post request
variables in context data (such as form)
assert template used
creation of object on post request in case of create view
check for permissions using status codes
The thing is tests on django views are technically integration tests. As long as your tests are granular enough, means you don't test code for forms or models in views, I don't see any problem provided you follow Classical TDD.
I have a django app that processes both POST and GET requests.
What is "the best" way to design the view? Should I have separate methods to handle each type of request? Or should I just use one method? Or should the methods be dependent on the functionality?
Thanks in advance.
You could use function based views or Class based views:
In the first case:
# function based views
def my_view(request):
if request.method == 'POST':
# Handle post method
else: # request.method == 'GET'
# Handle get method
In the second case:
# Class based views
class MyView(View): # Use the view that fix your needs
def get(self, request, *args, **kwargs):
# Handle get method
return HttpResponse()
def post(self, request, *args, **kwargs):
# Handle post method
return HttpResponse()
EDIT:
The better solution for me was just using a permissions system, especially since I needed other types of controlled access to objects. I now use Django-guardian to help with object level permissions like this.
Original:
I'm expanding a bit on the standard django book guide by letting users upload stories, as well as having author, publisher, etc. I'm attempting to only let authors (creators) of a story use the updateview, with other users being redirected away.
Modifying get_object in the UpdateStory view set it off, but the traceback goes through my StoryForm init for some reason. The error is 'HttpResponseRedirect' object has no attribute '_meta'
views.py
class UpdateStory(LoginRequiredMixin, UpdateView):
model = Story
template_name = 'stories/story_update.html'
form_class = StoryForm
def get_object(self, queryset=None):
obj = super(UpdateStory, self).get_object()
if not obj.author == self.request.user:
return redirect(obj)
return obj
forms.py
class StoryForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
super(StoryForm,self).__init__(*args, **kwargs)
I'm still new, so it might be obvious, but I've been looking for a couple hours and I'm stumped.
The best approach would be to use another mixin, something like this:
class AuthorRequiredMixin(object):
def dispatch(self, request, *args, **kwargs):
if self.object.author != self.request.user:
return HttpResponseForbidden()
return super(AuthorRequiredMixin, self).dispatch(request, *args, **kwargs)
Of course you can return another HttpResponse, but keep in mind what is the proper use here.
http://ccbv.co.uk/projects/Django/1.5/django.views.generic.edit/UpdateView/
Go through the above link to understand how UpdateView works. get_object is supposed to return the model instance, It is not supposed to return HttpResponseRedirect object, that's why you are getting that error.
Try doing the check in dispatch method like the following.
def dispatch(self, request, *args, **kwargs):
""" Making sure that only authors can update stories """
obj = self.get_object()
if obj.author != self.request.user:
return redirect(obj)
return super(UpdateStory, self).dispatch(request, *args, **kwargs)
PS: I guess it is not recommended to override dispatch. But as you
have to do the check on both get and post methods, overriding dispatch
will be easier.
This specific issue is considered in Django anti-patterns.
We're encouraged to filter the QuerySet to only retrieve objects where the user is the author, as opposed to UserPassesTestMixin.
In OP's case it would actually be quite similar to what they have there
from django.contrib.auth.mixins import LoginRequiredMixin
class UpdateStory(LoginRequiredMixin, UpdateView):
model = Story
# …
def get_queryset(self, *args, **kwargs):
return super().get_queryset(*args, **kwargs).filter(
author=self.request.user
)
I'm using Django's class based DetailView generic view to look up an object for display. Under certain circumstances, rather than displaying the object, I wish to back out and issue a HTTP rediect instead. I can't see how I go about doing this. It's for when a user hits an object in my app, but without using the canonical URL. So, for example, on StackOverflow URLs take the form:
http://stackoverflow.com/<content_type>/<pk>/<seo_friendly_slug>
eg:
http://stackoverflow.com/questions/5661806/django-debug-toolbar-with-django-cms-and-django-1-3
You can actually type anything as the seo_friendly_slug part and it will redirect you to the correct canonical URL for the object looked up via the PK.
I wish to do the same in my DetailView. Retrieve the object, check that it's the canonical URL, and if not redirect to the item's get_absolute_url URL.
I can't return an HttpResponseRedirect in get_object, as it's expecting the looked up object. I can't seem to return it from get_context_data, as it's just expecting context data.
Maybe I just need to write a manual view, but I wondered if anyone knew if it was possible?
Thanks!
Ludo.
This isn't a natural fit for DetailView. To do this you need to override the get method of BaseDetailView, which looks like:
class BaseDetailView(SingleObjectMixin, View):
def get(self, request, **kwargs):
self.object = self.get_object()
context = self.get_context_data(object=self.object)
return self.render_to_response(context)
So in your class you'd need to provide a new get method which did the URL check between fetching the object and setting up the context. Something like:
def get(self, request, **kwargs):
self.object = self.get_object()
if self.request.path != self.object.get_absolute_url():
return HttpResponseRedirect(self.object.get_absolute_url())
else:
context = self.get_context_data(object=self.object)
return self.render_to_response(context)
As you end up overriding so much of the functionality it becomes questionable whether it's worth actually using a generic view for this, but youknow.
Developing on Rolo's answer and comments, I came up with the following generic view to serve this purpose:
from django import http
from django.views import generic
class CanonicalDetailView(generic.DetailView):
"""
A DetailView which redirects to the absolute_url, if necessary.
"""
def get_object(self, *args, **kwargs):
# Return any previously-cached object
if getattr(self, 'object', None):
return self.object
return super(CanonicalDetailView, self).get_object(*args, **kwargs)
def get(self, *args, **kwargs):
# Make sure to use the canonical URL
self.object = self.get_object()
obj_url = self.object.get_absolute_url()
if self.request.path != obj_url:
return http.HttpResponsePermanentRedirect(obj_url)
return super(CanonicalDetailView, self).get(*args, **kwargs);
This is used in the same manner as the normal DetailView, and should work for any model which implements get_absolute_url correctly.