I can't understand the class based views, so I am trying to figure it out with an example. Here is what I have so far:
#urls.py
url(r'^(?P<langcode>[a-zA-Z-]+/about/$', about, name='about')
#views.py
def about(request, langcode):
languages = Language.objects.values_list('code', flat=True)
language = get_object_or_404(Language, pk=langcode)
return render(request, 'about.html', {
'languages': languages,
'language': language
})
I also have some other functional views which contain the first 2 lines of about:
languages = Language.objects.values_list('code', flat=True)
language = get_object_or_404(Language, pk=langcode)
So, what I want to do now is:
create a class BaseView (or however you want to call it) which extends
something from django.generic.views and which will determine the language and languages parameters for the context based on the langcode input parameter
Create the class AboutView(BaseView) (so extending the BaseView) which will somehow define the template name about.html to be used for rendering.
I will further have another class based view, also to extend BaseView and which is simillar to AboutView, but which sets one more context parameter called region depending as well on the langcode input parameter
Can someone show me exactly how to code this stuff? thank you
Here's a simple way to achieve what you want:
You first define the common logic, using the TemplateView generic view:
class MyBaseView(TemplateView):
def dispatch(self, request, *args, **kwargs):
# dispatch takes care of "reading" the parameters from the url
self.language = get_object_or_404(Language, pk=kwargs.pop("langcode")) # I would use some kind of default value to prevent exception, but its up to your logic
return TemplateView.dispatch(self, request, *args, **kwargs)
def get_context_data(self, **kwargs):
# get_context_data creates the context
context = TemplateView.get_context_data(self, **kwargs)
context.update({"language": self.language,
"languages": Language.objects.values_list('code', flat=True)})
return context
Then, you don't even need an AboutView because all you want is to control the template_name, so in your urls.py:
# in urls,py you can just use this, instead of defining an AboutView, you pass the template_name you want to use, this is sufficient because TemplateView expects a template_name attribute
url('^(?P<langcode>[a-zA-Z]+)/about/$', MyBaseView.as_view(template_name="about.html"), name='about')
and finally, for the other view that uses region you can just inherit from the MyBaseView, and add the context you want:
class AboutViewWithRegion(MyBaseView):
def get_context_data(self, **kwargs):
context = MyBaseView.get_context_data(self, **kwargs)
context.update({"region": <<your logic here>>})
return context
Hope that helps!
Related
I have a Django application that uses a JSON API as its data source.
Here's a simplified example of use in one of my views.py:
class GroupsList(LoginRequiredMixin):
def get(self, request, **kwargs):
# Get file list and totals
try:
group_list = group_adapter.list() # makes an API call and ALSO populates a meta info class
except APIAccessForbidden:
return HttpResponseRedirect(reverse('logout'))
return render(request, 'groups/index.html', {
# can I make a mixin to add data here gained from the API call?
'group_list': group_list,
})
This line:
The group_adapter.list() call populates some meta information into another class, that's not related to the group_list itself. I'd like to pass that data to the template. Ordinarily I'd use a context_processor, but when the context processor is called, the API call hasn't been made yet. I could manually check the information and add it to the render() method, but then I'd need to do that in dozens of different views.
Potential Solution #1: Create a Mixin For It
Can I use a mixin here that adds this information to context AFTER the view code runs but BEFORE render passes information to the template?
In other words is there a way to do this:
class GroupsList(LoginRequiredMixin, AddMetaInfoToContextMixin):
and then create a mixin something like this?
class AddMetaInfoToContextMixin(ContextMixin):
def get_context_data(self, **kwargs):
# self.request
context = super().get_context_data(**kwargs)
context['global_meta_information'] = get_global_meta_information()
return context
Potential Solution #2: Make an overridden templateview
Commenter Melvyn pointed out that I can potentially subclass TemplateView and override get_context_data(), so would something like this work?
class TemplateViewWithMeta(TemplateView):
def get_context_data(self, *args, **kwargs):
context = super(Home. self).get_context_data(*args, **kwargs)
context['global_meta_information'] = get_global_meta_information()
return context
class GroupsList(LoginRequiredMixin, TemplateViewWithMeta):
[...]
The typical workflow for a Django generic TemplateView is:
get()
get_context_data()
render_to_response()
So in your case keeping with the spirit of generic views, you could do it like this:
from django.views import generic
class BaseRemoteApiView(generic.TemplateView):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.group_list = None
def get(self, request, *args, **kwargs):
try:
self.group_list = group_adapter.list() # makes an API call and ALSO populates a meta info class
except APIAccessForbidden:
return HttpResponseRedirect(reverse('logout'))
return super().get(request, *args, **kwargs)
class RemoteApiContextMixin(generic.base.ContextMixin):
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["group_list"] = self.group_list
context["meta_information"] = get_global_meta_information()
return context
class ConcreteRemoteApiView(RemoteApiContextMixin, BaseRemoteApiView):
pass
Of course, you don't have to make 3 classes and can just combine the 3 into one - depends on how mixable you want to be.
I have many views that call the same functions every time and I wonder before I go ahead with this approach if anyway I can make it more DRY.
For example I have many pages on a site that have on the left side menu a list of the same articles and photos. So on each of my views I do the following:
context_dict = {'articles': get_articles(blogger.id), 'photos': get_photos(blogger.id)}
return render_to_response('...', context_dict, context)
It must exist a way that I don't have to repeat myself every time since they are required on 90% of the pages.
The issue of repeating view functionality is part of why many people like class-based views. You could implement a method that adds those variables to the base class, and then have other views inherit from that one, or provide a standardized "render" method. For example:
class BaseView(View):
template = 'public/base_template.html'
def get(self, *args, **options):
return render_to_response(self.template, self.render_view())
def render_view(self, *args, **options):
context = {"photos": Photo.objects.all()}
return context
class OtherView(BaseView):
template = 'public/other_template.html'
def render_view(self, *args, **options):
context = super(OtherView, self).render_view(*args, **options)
context['additional_context'] = True
return context
...or something similar. Then, you don't have to worry about calling render with variables that are already included.
I can think of a few ways to accomplish this with function-based views, but I think class-based lends itself very well to DRY principles, so I thought I'd spread the gospel :)
https://docs.djangoproject.com/en/1.9/topics/class-based-views/intro/
You mean something like
def get_extra_context(blog_id):
return {'articles': get_articles(blogger.id), 'photos': get_photos(blogger.id)}
A call to get_extra_context has to be made in every view of course.
As Robert Townley says, class based views are very helpful for keeping to DRY principles. I often use some simple mixins to share some logic between different views. Your class based views can then inherit from this mixin if they need this functionality. For example:
class BloggerMixin(object):
articles_context_name = 'articles'
photos_context_name = 'photos'
def get_blogger(self):
""" I'm just assumming your blogger is the current user for simplicity.
(And I'm assuming they're logged in already)"""
return self.request.user
def get_articles(self):
return Article.objects.filter(blogger=self.get_blogger())
def get_photos(self):
return Photo.objects.filter(blogger=self.get_blogger())
def get_context_data(self, **kwargs):
context = super(BloggerMixin, self).get_context_data(**kwargs)
context[self.articles_context_name] = self.get_articles()
context[self.photos_context_name] = self.get_photos()
return context
This would allow you to inherit this extra functionality on class based views that need it:
class ExampleView(BloggerMixin, ListView):
model = SomeOtherModel
Our very simple ExampleView class will now have a list of Article, Photo and SomeOtherModel in its context.
If I have a class based view, like this,
class SomeView (View):
response_template='some_template.html'
var1 = 0
var2 = 1
def get(self, request, *args, **kwargs):
return render_to_response(self.response_template, locals(), context_instance=RequestContext(request))
My question is, inside the template some_template.html, how do I access var1 and var2? As far as I understood this, the locals() sort of just dumps all the local variables into the template, which has worked very well so far. But these other variables aren't technically "local", they're part of a class, so how do I pass them over??
Thanks!
A cleaner way of doing this could be to replicate Django's Template view:
class TemplateView(TemplateResponseMixin, ContextMixin, View):
"""
A view that renders a template. This view will also pass into the context
any keyword arguments passed by the url conf.
"""
def get(self, request, *args, **kwargs):
context = self.get_context_data(**kwargs)
return self.render_to_response(context)
and then adding it to the get_context_data function. Or you could simply use the TemplateView which will allow you to specify a template name and then you could override the get_context_data function:
class SomeView(generic.TemplateView):
var1 = 0
var2 = 1
template_name = 'some_template.html'
def get_context_data(self, **kwargs):
context = super(SomeView, self).get_context_data(**kwargs)
context.update({'var1': self.var1, 'var2': self.var2})
return context
EDIT
Django has generic views which you can use for a variety of things, I would strongly advise you to go look at the docs for a full list of them, These generic views have functions you can override to do custom things which aren't supported by default. In your case you just wanted a template with context variables on them which means you subclass the TemplateView and supply the template_name and then finally you can override the get_context_data function to add your context data and that would be all there is to it, the second piece of code would be all you need in your case.
Add self.var1 and self.var2 to the context in get method:
class SomeView (View):
response_template='some_template.html'
var1 = 0
var2 = 1
def get(self, request, *args, **kwargs):
context = locals()
context['var1'] = self.var1
context['var2'] = self.var2
return render_to_response(self.response_template, context, context_instance=RequestContext(request))
Note: render_to_response() is removed in Django 3.0 and above (use render() instead).
Also, I'm not sure that passing locals() as a context to the template is a good practice. I prefer to construct the data passed into the template explicitly = pass only what you really need in the template.
There are two approaches as you can see here. The first one, you can declare a function named get_context_data like this:
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
new_context_entry = "here it goes"
context["new_context_entry"] = new_context_entry
return context
If you are using Django 2.x you must pass *args in get_context_data too.
The second approach is modifying extra_context variable in some function in the view:
self.extra_context["another_one"] = "here goes more"
For passing your class label variable inside a function, you need to refer with self which refer as a newly created object. As we know for accessing any variable in class we need to refer to its object. Otherwise, it will be caught global name 'your variable' is not defined
as an example in your case you can do it like
class YourView(genericView):
template_name='your_template.html'
var1 = 12
var2 =1
def get(self, **kwargs):
context = locals()
context['var1'] = self.var1
context['var2'] = self.var2
return context
I've been experimenting with Django's Class Based Views and am trying to write a simple class based view that processes certain information in request so that the processed information can be used by the "handler" method.
I don't seem to have fully understood what the docs say and am unsure of whether this should be a Mixin, a generic view or something else. I'm thinking of making a class like this:
class MyNewGenericView(View):
redirect_on_error = 'home'
error_message = 'There was an error doing XYZ'
def dispatch(self, request, *args, **kwargs):
try:
self.process_information(request)
# self.process_information2(request)
# self.process_information3(request)
# etc...
except ValueError:
messages.error(request, self.error_message)
return redirect(self.redirect_on_error)
return super(MyNewGenericView, self).dispatch(request, *args, **kwargs)
def process_information(self, request):
# Use get/post information and process it using
# different models, APIs, etc.
self.useful_information1 = 'abc'
self.useful_information2 = 'xyz'
def get_extra_info(self):
# Get some extra information on something
return {'foo':'bar'}
This will allow someone to write a view like:
class MyViewDoesRealWork(MyNewGenericView):
def get(self, request, some_info):
return render(request, 'some_template.html',
{'info':self.useful_information1})
def post(self, request, some_info):
# Store some information, maybe using get_extra_info
return render(request, 'some_template.html',
{'info':self.useful_information1})
Is the above code the right way to go? Is there any simpler/better way of doing this? Will this prevent the above functionalities from being used in another generic view (e.g. a built-in generic view)?
Have a look at this. great example code. http://www.stereoplex.com/blog/get-and-post-handling-in-django-views
It seems I just asked a stupid question.
This can easily be achieved by making a class that processes that information:
class ProcessFooInformation(object):
def __init__(self, request):
self.request = request
#property
def bar(self):
baz = self.request.GET.get('baz', '')
# do something cool to baz and store it in foobar
return foobar
# etc...
Then using old style function views or new class-based views:
def my_view(request):
foo = ProcessFooInformation(request)
# use foo in whatever way and return a response
return render(request, 'foobar.html', {'foo':foo})
I also made this more efficient by using lazy evaluation of properties.
I adapted ideas from the lazy property evaluation recipe and the comments to write a wrapper:
def lazy_prop(func):
def wrap(self, *args, **kwargs):
if not func.__name__ in self.__dict__:
self.__dict__[func.__name__] = func(self, *args, **kwargs)
return self.__dict__[func.__name__]
return property(wrap)
This evaluates the value of the wrapped method only once per instance and uses a stored value on subsequent calls. This is useful if the property evaluates slowly.
With function based Django view it was simple to switch between several different views based on a condition, e.g. something like:
def base_view(request):
if some_condition():
return foo_view(request)
else:
return bar_view(request)
I can't find a simple way to do the same with the new class-based generic views. The only way I can think of is to redisrect, which I would like to avoid for various reasons:
def base_view(request):
if some_condition():
return redirect(reverse("name_of_url_to_class-based_view_foo"))
else:
return redirect("/url_to_class-based_view_bar/")
Any suggestions?
This is equivalent to your example with class based views.
class FooView(View):
pass
class BarView(View):
pass
class BaseView(View):
# staticmethod to avoid adding 'self' to the arguments
foo_view = staticmethod(FooView.as_view())
bar_view = staticmethod(BarView.as_view())
def dispatch(self, request, *args, **kwargs):
if some_condition():
return self.foo_view(request, *args, **kwargs)
else:
return self.bar_view(request, *args, **kwargs)
Even though the Django docs do say that the function based generic views are now deprecated I think the only reason to switch would be if you're writing less code.
If you're still set on switching, you'll want to first identify which class based views or mixins are most appropriate (single object, multiple objects, date based, forms, etc.). If the conditional was used to select a function that returns different context data / template to provide to the view, you can push the conditional down into an overridden get_queryset|get_context_data|get_object|get_template_names depending on your use case.
For example,
def get_context_data(self, **kwargs):
# Call the base implementation first to get a context
context = super(BaseView, self).get_context_data(**kwargs)
# Add in the publisher
if some_condition():
context['some_data'] = ...
else:
context['other_data'] = ...
return context
If all else fails and you're still determined to have class based views, you could probably also override get(self, request, *args, **kwargs) and do the switching there to the appropriate method. The detailed docs are getting better but I've still found myself poking through the source code to figure out how to accomplish what I want.