We Keep Coding

How to avoid repeated code in views in Django?

I have several function based views in a django project, and I noticed that they have some repeated code, in fact, they all do the same thing:
def my_view(request):
form = MyForm(request.POST or None)
if requqest.POST:
if form.is_valid():
do_somethin()
and_something_else()
return redirect('another:page')
return render(request, 'my/tempalate.html', {'form': form})
The only thing that is different is the url where the user is redirected to in case of a succcesful form validation, the template, and maybe the form in the future.
Is it a good idea to use something like this to avoid that repetition?:
def a_view(request, success_redirect_url, template):
form = MyForm(request.POST or None)
if request.POST:
if form.is_valid():
do_something()
and_something_else()
return redirect(success_redirect_url)
return render(request, template, {'form': form})
and then reuse it in other views that have the repeated code? like:
def my_view1(request, url='another_page', template='my/template.html'):
return a_view(request, url, template)

Typically such patterns are defined in class-based views where one can use inheritance to override only some parts of the code flow.
Class-based views
Your view for example looks quite similar to a FormView [Django-doc]. Indeed, we can define a view with:
# app_name/views.py
from django.urls import reverse_lazy
from django.views.generic import FormView
class MyView(FormView):
template_name = 'my/template.html'
success_url = reverse_lazy('another_page')
form_class = MyForm
def form_valid(self, form):
do_somethin()
and_something_else()
return super().form_valid(form)
Here the class-based view has implemented a handler for a POST request that will first construct the form, then check if that form is valid, and if it is invalid rerender the template with the form that now contains the errors. It thus minimizes the amount of code that one has to write to handle a simple form.
Such views also explain clearly what they are doing. A CreateView for example explains by its name that it is used to create new objects, it will thus trigger the .save() method of the form it is operating on. A DeleteView on the other hand makes it clear that a POST request to that view will delete an object.
You can also override the attributes in the urls.py by specifying a value in the .as_view(…) [Django-doc] call:
# app_name/urls.py
from app_name.views import MyView
from django.urls import path
urlpatterns = [
# ⋮,
path('some/path/', MyView(template_name='other/template.html'), name='some-name'),
# ⋮
]
A class-based function thus acts as a template method pattern
Decorators
Another way to do this is to work with decorators that implement small pieces of logic that run before/after a call to the function-based view, and can alter the request/response, or decide to raise an error instead of calling the view.
For example the #require_http_methods(…) decorator [Django-doc] [GitHub] is implemented to first check if the method is one of the listed ones. This is implemented as:
def require_http_methods(request_method_list):
# ⋮
def decorator(func):
#wraps(func)
def inner(request, *args, **kwargs):
if request.method not in request_method_list:
response = HttpResponseNotAllowed(request_method_list)
log_response(
'Method Not Allowed (%s): %s', request.method, request.path,
response=response,
request=request,
)
return response
return func(request, *args, **kwargs)
return inner
return decorator
here the decorator thus checks if the request.method is a member of the request_method_list. If that is not the case, it will return a HTTP 405 response, and specify that that method is not allowed.
While Django offers a lot of decorators, most decorators have a mixin counterpart for a class-based views, and some are implemented already in the View class. For example if the View does not contains a get method, then it will return a HTTP 405 response, so here the required_http_method is not needed as a mixin/decorator for a class-based view.
Skeleton functions
You can implement a view function and use parameters instead to pass values. Usually however this will not be as flexible as a class-based view: it is rather easy to pass some parameters, but it is less useful to specify behavior in a pattern: in that case you need to pass a reference to a function, but then the question arises what parameters should be passed to that.
For example if we want to make a function that renders the template, we can work with a view that looks like:
from django.shortcuts import render
def render_some_template(request, parameter, context_generator, template='our/template.html'):
context = context_generator()
return render(request, template, context)
but perhaps the context_generator function should be called together with the parameter? or perhaps know what template will be rendered. This is one of the reasons why altering code flow is usually done with a class-based view, and less with a function-based view.
While a function-based view can work with a skeleton function, it is usually less exendible than the class-based counterpart. Django's builtin apps (the ones defined in the django.contrib module) are moving mainly towards class-based views, since it is easier to extend these.

You can do a lot better if just give a name to any button wich lunch this function:
<button name='lukaku'>
<button name='ronaldo'>
then into the view check for the name
if form.get('lukaku'):
do something
if form.get('ronaldo'):
do other thing
and so on. this can be limitless

DRF (django-rest-framework) action decorator not working

I have this class view, that works perfectly for creating and listing objects of SiteGroup:
But I need a method to perform several operations on a single SiteGroup object, and objects associated with them. Therefore, I have tried to create a method, decorated with #action (as suggested by the docs).
According to the docs, this will autogenerate the intermediate url. Nevertheless, it doesn't work.
When I try to access (given that 423 is an existing SiteGroup Object):
http://127.0.0.1:8000/api/site-groups/423/replace_product_id/?product_id=0x345
the url is not found.
I also tried generating myself the URL in the urls.py, with no luck.
Can someone tell me where the problem is? I've browsed through all the docs, and found no clue. Thanks a lot.
class SiteGroupDetail(generics.ListCreateAPIView):
queryset = SiteGroup.objects.all()
parser_classes = (MultiPartParser, FormParser, JSONParser)
serializer_class = SiteGroupSerializer
authentication_classes = (authentication.TokenAuthentication,)
#action(detail=True, methods=['post'], url_path='replace_product_id', permission_classes=[IsSuperUser], url_name='replace_product_id')
def replace_product_id(self, request, pk=None, device_type=None):
serializer = SiteGroupSerializer(data=request.data)
product_id = self.request.query_params.get('product_id', None)
print("replace_product", product_id, device_type, pk, flush=True)
return Response({"hello":product_id})
My urls.py
from django.conf.urls import url, include
from api import views, routers
router = routers.SimpleRouter()
router.register(r'users', views.UserViewSet)
router.register(r'groups', views.GroupViewSet)
urlpatterns = [
url(r'^', include(router.urls)),
enter code here
url(r'^site-groups/', views.SiteGroupDetail.as_view()),
url(r'^site-groups/(?P<pk>[0-9]+)/$', views.SiteGroupDetail.as_view()),
]

For one thing the router should be calling
super(OptionalSlashRouter, self).__init__()
What you have now calls __init__ of SimpleRouter's parent, skipping the logic in SimpleRouter.__init__
Change that and see if it starts working
Actually as you're using python 3 it could be just
super ().__init__()

Sucess_url based on pk in GenericView from urls.py

In my url.py I have urls like:
url(r'^messstellen/monatlicher_verbrauch/(?P<pk>[0-9]+)/update/$',
generic.UpdateView.as_view(
model=MonatlicherVerbrauch,
form_class=MonatlicherVerbrauchForm,
success_url=reverse('messstellen:messstellen_index'),
template_name='messstellen/monatlich_form.html',
),
now I want to let the success_url be something like:
success_url = redirect('messstellen:messtelle_detail', pk=pk)
where the pk schould be the same like in the regex pattern (?P<pk>[0-9]+)
Is there a way to do it in the url.py view?

If you don't define success_url, then Django will use your model's get_absolute_url method, which you could define as:
class MonatlicherVerbrauch(models.Model):
...
def get_absolute_url(self):
return reverse('messstellen:messtelle_detail', args=[self.pk])
If your get_absolute_url points to a different url, then I don't think it is possible to set the success_url dynamically in the urls. You will have to override the view, and define get_success_url.
class MonatlicherVerbrauchUpdateView(UpdateView):
def get_success_url(self):
return reverse('messstellen:messtelle_detail', args=[self.object.pk])
# define these attributes in the view as well, to keep urls simple
model=MonatlicherVerbrauch,
form_class=MonatlicherVerbrauchForm,
template_name='messstellen/monatlich_form.html',
Then use MonatlicherVerbrauchUpdateView in your urls instead of UpdateView.
url(r'^messstellen/monatlicher_verbrauch/(?P<pk>[0-9]+)/update/$',
MonatlicherVerbrauchUpdateView.as_view()),
The advantage of subclassing the generic view is that it separates the logic of your views from the urls.

Django: Generic views based 'as_view()' method

I was working on an application wherein I created a generic ListView. Now, while defining that view in my urls.py, I read from the documentation that I need to use the as_view() method as follows:
from django.conf.urls import patterns, include, url
from .views import BlogIndex
urlpatterns = patterns(
'',
url(r'^$', BlogIndex.as_view(), name="index"),
)
Now, I didn't really understood what the documentation had to say about this method. Can someone shed some light into this concept?

In Class-based views, you have to call as_view() function so as to return a callable view that takes a request and returns a response. Its the main entry-point in request-response cycle in case of generic views.
as_view is the function(class method) which will connect my MyView class with its url.
From django docs:
classmethod as_view(**initkwargs)
Returns a callable view that takes a request and returns a response:
You just can't use class-based views like you could in normal function-based views.
BlogIndex(request) # can't do this in case of CBVs
The above code is not valid if you want the CBVs to function properly. For that, you need to provide a view which is callable and then pass request to it. For example:
response = MyView.as_view()(request) # valid way
By calling the as_view() function on my view class MyView will give me a view which i will call with request parameter to initiate the request-response cycle.
In your case:
my_callable_view = BlogIndex.as_view() # returns a callable view
<function blog.views.BlogIndex>
Now, call this function and pass the request.
response = my_callable_view(request) # generate proper response

view function have different format than before because :
This view will actually be implemented as a class
We will be inheriting from an existing generic view function that already does most of what we want this view function to do, rather
than writing our own from scratch.
Class method as_view()- this does all the work of creating an instance of the class, and making sure that the right handler methods
are called for incoming HTTP requests.
ref : https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Generic_views

Maybe I can try to write the as_view with pseudo-code:
class ViewClass():
#other stuff
def as_view(self):
return self.render(*args)
It return the render function inside the CBV.
So it actually is the same as path('some_path',views.some_view_function,name='some_name')
Of course, there there is actually much more things going on than only render function, for example to verify and save the content inside post queryDict, actually you need def post(): to handle the post, in function you just if request.method == 'POST' they are actually mutual.
To be specific, as_view() just generate a overall function, including if request.method =='POST': #some code Maybe the actual code doesn't work like that, but you could understand it this way if you are not prepared to contribute to django source code yourself.

Django class-based view

Django
Following the official documentation, I am creating a Django app (the same poll app as in the documentation page). While using the class-based view, I got a error. I did not understand much about class based view, for instance, may someone explain, what is the difference between a class based view from a normal view?
Here's my code:
class DetailView(generic.DetailView):
model = Poll
template_name = 'polls/details.html'
def get_queryset(self):
def detail(request, poll_id):
try:
poll = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise Http404
return render(request, 'polls/details.html', {'poll': poll})
*********************Error ********************
TypeError at /polls/2/results/
as_view() takes exactly 1 argument (3 given)
Request Method: GET
Request URL: <app-path>/polls/2/results/
Django Version: 1.5.1
Exception Type: TypeError
Exception Value:
as_view() takes exactly 1 argument (3 given)
*****the url***
url(r'^(?P<pk>\d+)/$', views.DetailView.as_view, name='detail')

as_view should be called, not referenced, according to the docs, your url should look like:
url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail')
Note the usage of parenthesis.
Also, you should rather call your class PollDetailView to avoid confusion for code readers.
Also, the detail() method you have defined will not be called at all. So you shouldn't define it at all. Also, leave the get_queryset() method alone for the moment, try to get the basic View to work first.

When you use url for the CBV ensure that you can not use the reference of the of the url filed, so first you need to add change the as_view to as_view().
And you can use DetailView like this.,
class PollDetail(DetailView):
model=Book
def get_context_data(self,*args,**kwargs):
context=super(PollDetail,self).get_context_data(*args,**kwargs)
print(context) #It will give you the data in your terminal
return context
And for accessing data you need to use {{object}},
and if you want to access other fields at that time use like this {{object.fieldname}}
In CBV the template name is automatically named as per class name so you don't need to give it.
Note:Don't give class name same as DetailView,In future you will confuse.

Since you are not modifying the view functionality, to use this generic view, you can simply do this:
in your urls.py (along with other stuff):
from django.views.generic.detail import DetailView
from poll.models import Poll
url(r'^(?P<pk>\d+)/$',
DetailView.as_view(model=Poll,
template_name='polls/details.html'), name='detail')
Then in poll/details.html, you just need:
{{ object }}