This issue has been tormenting me for a while already. I've read about this topic but nothing seems to clear my thoughts. I understand that they call the views templates, and the models models as well, what I don't really get is where the controllers are. What django calls views seem to me more like actions/methods/functions of a controller than a controller itself, but anywhere I read, I find that supposed view-controller equivalency.
I've worked with MVC frameworks before (ASP.NET MVC3, Ruby on Rails, PHP Laravel Framework), and they all define the controllers as the same thing: a bunch of functions related to a specific topic of the site, namely user accounts or something like that. The best equivalency that I find between this description and django features are the apps, but of course I'm wrong due to the huge amount of people and documentation going the other way.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
It's a mistake to think of design patterns like MVC as unbreakable rules. They really aren't: there are all sorts of ways of implementing them, which comply with the description to a greater or lesser extent.
This is especially the case in Python, where one of the guiding principles is "practicality beats purity" - in other words, do what works.
In any case, Django makes no claim to be an MVC framework. On the contrary, the documentation describes it as MTV: model, template, view. After all, outside the world of design patterns everyone calls "an HTML file with syntax for variables and flow control" a template, not a view.
(That FAQ entry also offers a possible answer to your question: the controller is the framework itself. But it goes on to emphasise that it's a mistake to try to shoehorn into these definitions.)
The views.py defines the view functions for your app and your app groups related functions together.
However what I believe you're missing here is the urls.py.
The urls file is the first part of the controller.
The URL patterns inside urls.py dictates what you're allowed to pass in to the view function or view class (depending on what approach you took, either with function based views or class based views) and then routes it to the proper view function.
So there's tight a coupling between the views.py and the urls.py, that makes up for the entire Controller part of MVC.
Comparing it to Rails, would be that the urls.py is a routes.rb and the actual controller class is the views.py function/cbv.
The mismatch of terminology is unfortunate but more or less doing the same thing.
You can read the Django FAQ. It explains the how MVC is implemented in django. Regarding controller Django has an answer as:
.
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
The only well-defined parts of MVC where nearly everyone had some sort of consensus is the M; the V and C means completely different things in different web frameworks, to the point where MVC framework really only means as not having all your code in one spaghetti (ala typical classical PHP code). You just had to accept that MVC isn't a really well defined term.
Django is not strictly speaking MVC.
I found this discussion very enlightening:
Django is not MVC
Realy guys:
DJANGO is MVC!
But word View use for Controller.
And Django is Full MVC, but
Model - Model
View - Template
Comtroller - View
Related
I have followed several django tutorials. I do not know why controllers are stored in a file called views.py. I am confuse with this filename. I am looking for a MVC development. Are there other files in django for "real" controllers ?
The name views.py was a mistake
From an architecture point of view, it was a mistake to call views.py the module where functions receive an HTTP request and produce an HTTP response.
Such module is clearly a controller in the MVC sense. (For comparison, the equivalent functionality in the Spring framework is in a class with annotation #RestController or #Controller.)
Such module is also a REST adapter if you use the Ports & Adapter architecture style (aka Hexagonal architecture).
Such module deals with in-out data (request-response), but it is not a representation of the view displayed to the user. If not, what about an http DELETE endpoint (#api_view(['DELETE']))? What about an http POST endpoint that triggers background processing and has no bearing on what the Web UI shows? The functions in views.py are "handlers" of user actions (i.e., controller in MVC), not the representation of UI data.
I understand that views.py is a convention and you can use other names, but once the tutorial examples and other documentation use that name, it sticks.
Another mistake is when tutorials like this use the name views.py as the single place for all http endpoints. The name views.py is too generic and its very idea is an invitation to violate the Single Responsibility Principle (SRP).
Even simple tutorial examples, should use better names. For example:
if you're handling endpoints that deal with customer functionality, call it views_customer.py or customer_views.py (or better yet, customer_controller.py if you're bold to break with the convention and call it for what it is).
Yes ! Actually it's a design decision and It's described by the guys behind Django Here.
Basically their argument is that, in their opinion,
In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction.
a “view” is the Python callback function for a particular URL, because that callback function describes which data is presented.
I entice you to read the entry to get a hold of the overal idea behind the views naming.
About the controllers, Yes again. Mostly though, you can define several layers of the so called Middlewares in django to handle lots of your static logic before/after requests are handled by views, but still, it's the view that plays the main role of a controller in Django.
Look at this logically. What do you normally call a text file with placeholders which is filled with other bits of text by supplying variables? You call that a "template", you don't call that a "view". Only in MVC would you think of calling such a thing a "view".
I'm new to angular and I'm looking for a way to achive more advanced templating that one mentioned in the tutorial here
1.) I would like to have a different template for the login page and another one after you are logined
2.) it would be nice to have a functionality of multiple ng-view-s so you can have diferent pieces of the template filed diferently on every url...is it possible to achive this in angular
3.) is there a beter/easyer templating mechanisem to use, meybe some other js framework?
The ideall would be to use something like facelets but on client.
While it is not possible to have multiple ng-views, you can certainly have more than one routes, each one mapped to a controller and a view. It will help to do further reading on how to use controllers, routes etc. You can also use ng-include one ore more times with static or dynamic template urls mapped to a variable in the controller.
AngularJS is one of the best (if not the best) multi-feature JS UI frameworks available in terms of MVCness, extensibility, fine tuning, testing, data binding, templating etc. You cannot generally go wrong with it, just need to spend some time initially getting used to the patterns, idioms and terminology.
I would suggest looking into ui-router for doing nested views.
I accept that the question is a bit subjective, and that it does not pin point at certain technical doubt/query, but i wanted to know.
I am a newbie in django, after 3-4 months of doing apps in django i am trying to dig-down-deep.
I am currently reading a book by James Brennet where he shows how to use generic views, but when i head to https://docs.djangoproject.com/en/dev/topics/ i see generic views are depricated.
From the "best design perspective" point of view, how is using generic views rated?
Is it considered a good practice to use generic views?
If yes why is then django depricating it?
If no, what else is recommended?
Thanks!
The old generic views are deprecated because they've been replaced with 'Class-based generic views':
https://docs.djangoproject.com/en/dev/topics/class-based-views/
If you have a lot of view which repeatedly express the same pattern, for example a set of CReate/Update/Delete (CRUD) views for several models... where most of the view code is the same but just some specifics change, eg the model class and final redirect url... this is where generic views make sense.
The goal is to be DRY (Don't Repeat Yourself) ...ie write the code in one place and re-use, catch and fix bugs in one place etc.
I have just learnt about Django apps. I want to know that within one site, if I make different apps. like, users, profiles, polls, blogs,comments, jobs , applications then how can I manage them to make them intereactive? And is it how the concept of app should be? I want to have things loosely coupled that's why asking? Rails work on the way of REST, so do Django support that also with the use of apps? May be my questions seems a bit ambiguous because I am new to django and some of my concepts are still messed up.
Please tell what ever you know.
The general idea is that apps should be as loosely coupled as possible. The goal is to have completely self-contained functionality. Now, of course, that's not always possible and many times it even makes sense to bring in functionality from another app. To do that, you simply import whatever you need. For example, if your "blogs" app needed to work with your Comment model in your "comments" app you'd simply add the following to the top of the python file you're working in:
from comments.models import Comment
You can then use Comment as if it were defined right in the same file.
As far as REST goes, Django's views are much more fluid. You can name your view whatever you like; you need only hook it up to the right urlpattern in urls.py. Django views can return any content type, you just prepare the response and tell it what mimetype to serve it as (the default is HTML).
I've begun diving into Django again and I'm having trouble finding the parallel to some common concepts from my life in C#. While using .NET MVC I very often find myself creating a base controller which will provide a base action implementation to take care of the type of stuff I want to do on every request, like retrieving user information, getting localization values.
Where I'm finding myself confused is how to do this in Django. I am getting more familiar with the MVT concept but I can't seem to find how to solve this scenario. I've looked at class based views and the generic views yet they didn't seem to work how I expected. What am I missing? How can i create default logic that each view will be instructed to run but not have to write it in each view method?
If it is truly common for your whole site you use middleware. If it is only common for some views, the way to go in my opinion is to create decorators for those views. I never use class-based views because I tend to keep views simple and put more logic into models, so I have no need for classes there.