I recently learned that you should override the get method when you specifically want to do something other than what the default view does:
class ExampleView(generic.ListView):
template_name = 'ppm/ppm.html'
def get(self, request):
manager = request.GET.get('manager', None)
if manager:
profiles_set = EmployeeProfile.objects.filter(manager=manager)
else:
profiles_set = EmployeeProfile.objects.all()
context = {
'profiles_set': profiles_set,
'title': 'Employee Profiles'
}
That's simple enough, but when should I use get_queryset or get_context_data over get? To me it seems like they basically do the same thing or am I just missing something? Can I use them together? This is a major source of confusion for me.
So to reiterate: In what cases would I use get over get_queryset or get_context_data and vise versa?
They indeed do different things.
get()
This is a top-level method, and there's one for each HTTP verb - get(), post(), patch(), etc. You would override it when you want to do something before a request is processed by the view, or after. But this is only called when a form view is loaded for the first time, not when the form is submitted. Basic example in the documentation. By default it will just render the configured template and return the HTML.
class MyView(TemplateView):
# ... other methods
def get(self, *args, **kwargs):
print('Processing GET request')
resp = super().get(*args, **kwargs)
print('Finished processing GET request')
return resp
get_queryset()
Used by ListViews - it determines the list of objects that you want to display. By default, it will just give you all for the model you specify. By overriding this method you can extend or completely replace this logic. Django documentation on the subject.
class FilteredAuthorView(ListView):
template_name = 'authors.html'
model = Author
def get_queryset(self):
# original qs
qs = super().get_queryset()
# filter by a variable captured from url, for example
return qs.filter(name__startswith=self.kwargs['name'])
get_context_data()
This method is used to populate a dictionary to use as the template context. For example, ListViews will populate the result from get_queryset() as author_list in the above example. You will probably be overriding this method most often to add things to display in your templates.
def get_context_data(self, **kwargs):
data = super().get_context_data(**kwargs)
data['page_title'] = 'Authors'
return data
And then in your template, you can reference these variables.
<h1>{{ page_title }}</h1>
<ul>
{% for author in author_list %}
<li>{{ author.name }}</li>
{% endfor %}
</ul>
Now to answer your main question, the reason you have so many methods is to let you easily stick your custom logic with pin-point accuracy. It not only allows your code to be more readable and modular, but also more testable.
The documentation should explain everything. If still not enough, you may find the sources helpful as well. You'll see how everything is implemented with mixins which are only possible because everything is compartmentalized.
Let's look at the default implementation of ListView's get method:
https://github.com/django/django/blob/92053acbb9160862c3e743a99ed8ccff8d4f8fd6/django/views/generic/list.py#L158
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:
# When pagination is enabled and object_list is a queryset,
# it's better to do a cheap query than to load the unpaginated
# queryset in memory.
if (self.get_paginate_by(self.object_list) is not None
and hasattr(self.object_list, 'exists')):
is_empty = not self.object_list.exists()
else:
is_empty = len(self.object_list) == 0
if is_empty:
raise Http404(_("Empty list and '%(class_name)s.allow_empty' is False.")
% {'class_name': self.__class__.__name__})
context = self.get_context_data()
return self.render_to_response(context)
You will notice that get_queryset gets called in the first line. You can simply overwrite that if you just want to return your model's queryset after applying some filtering/ordering etc.
You don't need to overwrite the whole get method for that because you will be missing on all this provided functionality i.e. pagination, 404 checks etc.
get_context_data merges the resulting queryset together with context data like querystring parameters for pagination etc.
What I would recommend would be to check with django's source every once in a while and try to understand it a little bit so that you can recognize the most appropriate method you can overwrite/replace.
Related
I've been learning Django and one source of confusion I have is with class based views and when to override the get method. I've looked through the documentation and it explains what get does but it doesn't explain when I should override get.
I originally created a view this way:
class ExampleView(generic.ListView):
template_name = 'ppm/ppm.html'
paginate_by = 5
def get(self, request):
profiles_set = EmployeeProfile.objects.all()
context = {
'profiles_set': profiles_set,
'title': 'Employee Profiles'
}
return render(request, self.template_name, context)
But I was recently told that my code was simple of enough for the default implementation, and that all I needed was this:
class ExampleView(generic.ListView):
model = EmployeeProfile
template_name = 'ppm/ppm.html'
So my Question is this: In what scenario/circumstance should I override the get method?
If you are using the builtin generic views, then you should rarely have to override get(). You'll end up either duplicating lots of functionality, or break features of the view.
For example, the paginate_by option will no longer work in your view, because you are not slicing the queryset in your get() method.
If you are using a generic class based view like ListView, you should try to override specific attributes or methods where possible, rather than overriding get().
The advantage of your view which overrides get() is that it's very clear what it does. You can see that the view fetches a queryset, includes it in a context, then renders the templates. You don't need to know about ListView to understand the view.
If you like the explicitness of overriding get() subclass View instead. You aren't using any of the features of ListView, so it doesn't make sense to subclass it.
from django.views.generic import View
class ExampleView(View):
template_name = 'ppm/ppm.html'
def get(self, request):
...
You should override the get method when you specifically want to do something other than the default view does. In this case, your code isn't doing anything other than rendering the template with the list of all EmployeeProfile objects, which is exactly what the generic ListView would do.
You might override it if you want to do something more complicated. For example, maybe you want to filter based on a URL parameter:
class ExampleView(generic.ListView):
template_name = 'ppm/ppm.html'
def get(self, request):
manager = request.GET.get('manager', None)
if manager:
profiles_set = EmployeeProfile.objects.filter(manager=manager)
else:
profiles_set = EmployeeProfile.objects.all()
context = {
'profiles_set': profiles_set,
'title': 'Employee Profiles'
}
return render(request, self.template_name, context)
I'm new to django.
I'd like my users to be able to place orders. For this kind of order, the user uploads a csv. The app parses, the CSV, serializes the data, and then needs to show the user a new view with the data and a "confirm order" button. I'm not sure how to do this in django.
class UploadSampleSheetView(LoginRequiredMixin, FormView):
form_class = UploadSampleSheetForm
template_name = 'pages/upload.html'
def form_valid(self, form):
uploaded_sample_sheet = self.request.FILES['uploaded_sample_sheet']
sample = _parse_sample_sheet_to_sample_model(uploaded_sample_sheet)
sample.save()
return super().form_valid(form)
def get_success_url(self):
return reverse("orders:create") # how do I return another view populated with data here?
class CreateOrderView(LoginRequiredMixin, CreateView):
model = Order
form_class = NewOrderForm
template_name = 'pages/complete_order.html'
What I'm looking for is some way that, on success, the UploadSampleSheetView can return a CreateOrderView with sample data.
In general, I'd love to be pointed to a reference about how to build user flows like this one. How does one view defer to another? I'm seeing a lot of return HttpResponseRedirect('url') which seems a little messy. How do I pass data around views?
FormViews are supposed to return HttpResponseRedirects. They take in the data, process it, and re-route you to a place that makes sense. I think your question is, how can I get routed to the appropriate place.
The documentation isn't very clear on this, so it's a very valid question. But, you can override get_success_url to take in an argument. So, you would add this:
def get_success_url(self, sample_id):
return reverse('create_order', kwargs={"pk" : sample_id})
and also change form_valid to
def form_valid(self, form):
uploaded_sample_sheet = self.request.FILES['uploaded_sample_sheet']
sample = _parse_sample_sheet_to_sample_model(uploaded_sample_sheet)
sample.save()
return HttpResponseRedirect(self.get_success_url(sample.id))
Don't worry, you're not missing out on anything by skipping super().form_valid() -- the docs (scroll just a little down) say that all form_valid does by default is redirect to success_url.
You can use Form Wizard
Django comes with an optional “form wizard” application that splits forms across multiple Web pages. It maintains state in one of the backends so that the full server-side processing can be delayed until the submission of the final form.
You might want to use this if you have a lengthy form that would be too unwieldy for display on a single page. The first page might ask the user for core information, the second page might ask for less important information, etc.
Harder to use, but very useful and flexible.
# views.py
from formtools.wizard.views import SessionWizardView
class MyView(SessionWizardView):
template_name = 'pages/wizard_steps.html'
template_name_done = 'pages/wizard_done.html'
form_list = (
('upload', UploadSampleSheetForm),
('confirm', NewOrderForm)
)
def done(self, form_list, **kwargs):
# you can get all forms data here and process it as you want
return render(self.request, self.template_name_done, {
'form_data': [form.cleaned_data for form in form_list],
})
def process_step(self, form):
if isinstance(form, UploadSampleSheetForm):
# Example. You can put here some additional manipulations
pass
return super().process_step(form)
And template
<!-- wizard_done.html -->
{% if wizard.steps.current == 'upload' %}
{% include 'pages/wizard_upload.html' %}
{% elif wizard.steps.current == 'complete' %}
{% include 'pages/wizard_complete.html' %}
{% endif %}
I think you are looking for Django Session. This is an extensive document if you want to dive deep.
It includes the examples that you are looking for as well.
I'm trying to redirect users based on the referer in the request header. Basically, if the referer is say https://www.google.com, I would like to send them to a page, not on my website. Otherwise, continue processing as usual.
Here is what I have so far
class ArticleAccess(TemplateView, SomeMixin):
http_method_names = ['get']
template_name = 'template.html'
def dispatch(self, request, *args, **kwargs):
return super(ArticleAccess, self).dispatch(request, *args, **kwargs)
def get_context_data(self, **kwargs):
context = super(ArticleAccess, self).get_context_data(**kwargs)
item = get_object_or_404(ClientItem.objects.using(self.get_site().name), id=kwargs['article_id'])
if self.request.META.get('HTTP_REFERER') == 'https://www.google.com/':
return redirect(item.item_url)
context['id'] = item.id
context['name'] = item.name
context['html'] = item.description
context['item_url'] = item.item_url
return context
This just stays on the same page instead of redirecting. I have also tried HttpResponseRedirect, but to no avail
alecxe is correct.. you'd have to redirect from a method that is expected to return an HttpResponse.
get_context_data is not expected to return an HttpResponse and isn't ever returned by the view. It's always used to get a data dict to populate say a template. No matter what you return from this method, it will never override the response.
Therefore wherever you write this override, it needs to be in a place that is expected to return a response, such as get, post, dispatch.
The problem now is to determine how to get your object outside of the get_context_data method.
For debugging, I recommend you to start by just using a plain redirect('some_view') without conditions on your dispatch method so you can check if redirection is hit as expected and only then, go for conditions and anything else. #Yuji-tomita-tomita is just right! :) Django-pdb and ipdb are very nice tools.
I have a created a view class "class Demo", which has 3 functions
def update_time()
def get_context()
def before_response()
urls.py : url(r'^demo/$', Demo.as_view(),name='demo_class'),
When i'll enter url /demo/ how will it determine which function to call from "class Demo" ?
Because Django’s URL resolver expects to send the request and associated arguments to a callable function, not a class, class-based views have an as_view() class method which serves as the callable entry point to your class. The as_view entry point creates an instance of your class and calls its dispatch() method. dispatch looks at the request to determine whether it is a GET, POST, etc, and relays the request to a matching method if one is defined, or raises HttpResponseNotAllowed if not.
just read the docs
Basically class based views are recommended when you need to handle both get and post requests at one point. For example in get method of class Register, you can render the registration form and in its post method, you can handle the form submission. If its a get request it will automatically invoke the get() method in the class, same for post request. Also you can write any common code in the dispatch() method which will be invoked for every request.eg:
class Register(View):
def dispatch(self, *args, **kwargs):
'''
common code here
'''
return super(Register, self).dispatch(*args, **kwargs)
def get(self, request):
registration_form = RegistrationForm()
return render(request, 'new.html', { 'form': registration_form })
def post(self, request):
registration_form = RegistrationForm(request.POST or None)
if registration_form.is_valid():
#save form
return HttpResponseRedirect(reverse('success-show'))
return render(request,new.html', { 'form': registration_form })
For references you can check this website.
You need to subclass a class based views, and depending on that it will have one or another method.
For example TemplateView renders a template you pass in the template_name attribute.
All class based views care about is that the attributes needed to work properly are setted. That is done via different methods. You can check the django's documentation for specifics.
For example, if you want to render a form in your template view, you will need to pass the form in the context, so you can override get_context_data() like:
def get_context_data(self, **kwargs):
context = super(DemoClass, self).get_context_data(**kwargs)
context['form'] = MyForm()
return context
There are different methods to handle different things, like querysets, objects, etc.
They are not complicated, but they are specific. If a class based view does not fit what you need, it may be easier to implement the functionality from a more general view (View, TemplateView) than forcing a more specific one to do things it is not intended for.
slightly change the url
add numbers one to three in url and put the condition in your view.
Ex.
url(r'^abc/(?P<newid>.*)$', 'class_demo'),
so your url will be like abc/1 or abc/2 or abc/3
view
def class_demo(requests, newid):
if newid==1:
update_time()
elif newid==2:
get_context()
I'm migrating a project from Django 1.2 to Django 1.5. The project used function-based views such as this:
def notecard_product(request, stockcode):
if request.user.is_authenticated():
liked = Recommendation.objects.values_list('product_id',flat=True).filter(recommended=True, user=request.user)
unliked = Recommendation.objects.values_list('product_id',flat=True).filter(recommended=False, user=request.user)
extra_context = {"liked" : liked, "unliked":unliked}
else:
extra_context = {"liked" : [0], "unliked": [0]}
return object_detail(request, queryset=Product.objects.live(),
object_id=stockcode,
extra_context=extra_context,
template_name='products/notecard.html', template_object_name='notecard_product')`enter code here`
In this excerpt, stockcode is captured from the URL and used to determine object_id. So I'm wondering how I would do this in a class-based view. This is what I have so far:
class NotecardProductListView(ListView):
queryset=Product.objects.live()
pk=self.kwargs['stockcode']
template_name='products/notecard.html'
context_object_name='notecard_product'
def get_context_data(self, **kwargs):
context = super(BooksListView, self).get_context_data(**kwargs)
if self.request.user.is_authenticated():
liked = Recommendation.objects.values_list('product_id',flat=True).filter(recommended=True, user=self.request.user)
unliked = Recommendation.objects.values_list('product_id',flat=True).filter(recommended=False, user=self.request.user)
extra_context = {"liked" : liked, "unliked":unliked}
else:
extra_context = {"liked" : [0], "unliked": [0]}
context.update(extra_context)
return context
pk is the new name for the old object_id kwarg. Obviously, this code doesn't work, because I can't access self outside of a function. But I'm not really sure how to do this. I need to set pk to something in the keyword arguments, but can't find a way to do this, as pk needs to be set in the class body outside of any functions. I also don't really have a way to experiment and try things, because the entire project is broken right now due to deprecated function calls.
Thanks!
I'm not sure where you got the idea that pk is the new name for object_id, nor why you think that you need to set it to a value per request. The point of the class-level attributes in class-based views is that they are set per view class, not per instance: they refer to the place the view will go to look up the value, not the actual value itself.
Your first mistake is that the equivalent of the old object-detail view is, not surprisingly, DetailView, not ListView. As the documentation shows, ListView gets the ability to show an object detail via its inheritance from the SingleObjectMixin. That mixin expects a class-level attribute called pk_url_kwarg, which is the name of the argument captured from the URL which identifies the object's PK: in your case, this is the string 'stockcode'. The instance itself takes care of looking up that value in any particular request, you don't need to do it.