Changed docs/faq.txt MVC question to use clearer argument made in Jacob's Google presentation.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@2825 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Adrian Holovaty 2006-05-03 21:21:25 +00:00
parent fc7b5fa0ae
commit 332726981f
1 changed files with 24 additions and 8 deletions

View File

@ -125,16 +125,32 @@ Feel free to add your Django-powered site to the list.
Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names? Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
----------------------------------------------------------------------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------------------------------------------------------------------
That's because Django isn't strictly a MVC framework. If you squint the right Well, the standard names are debatable.
way, you can call Django's database layer the "Model", the view functions the
"View", and the URL dispatcher the "Controller" -- but not really.
In fact, you might say that Django is a "MTV" framework -- that is, Model, In our interpretation of MVC, the "view" describes the data that gets presented
Template, and View make much more sense to us. 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.
So, although we've been strongly influenced by MVC -- especially in the So, in our case, a "view" is the Python callback function for a particular URL,
separation-of-data-from-logic department -- we've also strayed from the path because that callback function describes which data is presented.
where it makes sense.
Furthermore, it's sensible to separate content from presentation -- which is
where templates come in. In Django, a "view" describes which data is presented,
but a view normally delegates to a template, which describes *how* the data is
presented.
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.
If you're hungry for acronyms, you might say that Django is a "MTV" framework
-- that is, "model", "template", and "view." That breakdown makes much more
sense.
At the end of the day, of course, it comes down to getting stuff done. And,
regardless of how things are named, Django gets stuff done in a way that's most
logical to us.
<Framework X> does <feature Y> -- why doesn't Django? <Framework X> does <feature Y> -- why doesn't Django?
----------------------------------------------------- -----------------------------------------------------