I don't want my MTV (model, template, view)

[Jason Huggins]

Well since you're looking for "last call" changes. :-)
(http://www.djangoproject.com/weblog/2005/jul/20/autoreload/)

Deep breath... Here goes:
* Rename Django "Views" by calling them "Controllers"
* Rename Django "Templates" by calling them "Views"

There, I said it. Django is 95% MVC, yet the "V" is in the wrong place.

The FAQ entry for this is an unconvincing argument for Django's name
change.
I don't see how you sufficiently moved away from "MVC" to warrant the
renaming.
Here's the URL for reference:
http://www.djangoproject.com/documentation/faq#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

When I first saw the Django demo at ChiPy, there was talk about Models,
Views, and Templates... I kept thinking... okay, where are the
controllers? I kept thinking... oh, you threw out controllers and
overloaded the Model with controller code... or maybe you overloaded
the Views... I now realize that's not exactly true. At the time, I
didn't realize you pulled a name change on me. :-) I fear this will be
the most common misunderstanding other noobs will have when hearing
about Django, especially in light of the inevitable comparisons to
other "MVC" frameworks.

If the MVC is there (just renamed), are there strong reasons to not use
the same names that most people expect to see?

Kindly-and-pythonically-yours,
-Jason

[Steadicat]

I'm not sure your interpretation of what a controller and a view should
be is as universal as you think.

I for one always felt that Rails got it wrong and Django's way is more
true to the original MVC.

I always assumed that the view is the collection of all the *code*
necessary to produce a user interface element. This code, in the case
of a web application, includes the HTML templates, of course, but
thinking that templates are all there is is a gross misconception.

"The view obtains data from the model and presents it to the user. The
view represents the output of the application."

http://en.wikipedia.org/wiki/MVC

Which is exactly what this code (a view from the Django tutorial) does:

def index(request):
latest_poll_list = polls.get_list(order_by=[('pub_date',
'DESC')], limit=5)
t = template_loader.get_template('polls/index')
c = Context(request, {
'latest_poll_list': latest_poll_list,
})
return HttpResponse(t.render(c))

"To preserve the Model View Controller pattern, presentation logic
should not be mixed with other kinds of logic in a program."

The code above is just extracting data from the model and presenting it
to the user. It belongs in a view, not in a controller.

"The controller is NOT a Mediator between the view and the model."

"The controllers are typically responsible for calling methods on the
model that *change the state* of the model."

http://www.phpwact.org/pattern/model_view_controller

And, anyway, "MVC was designed for a very specific requirement in a
specific environment, and is something of a square peg when it comes to
describing architectures such as web apps"

http://c2.com/cgi/wiki?WhatsaControllerAnyway

Just something to ponder on ;)

Cheers,

Stefano J. Attardi

[Jason Huggins]

Stefano (aka Steadicat) wrote:
> I for one always felt that Rails got it wrong and Django's way is more
> true to the original MVC.

Ahh... getting closer to a better FAQ answer already!

Perhaps, I want my "MTV" afterall, if webapps don't fit into the
classic definition of "MVC" very well. Plus, I'd rather use "MTV" as
its a cooler name, not-with-standing trademark problems with using the
name.

>"The controllers are typically responsible for calling methods on
> the model that *change the state* of the model."

So, I'm still left wondering, where do you define or what do you call
the code that processes a form... Would the form processor be
considered the "controller" in Django-land? Alas, the tutorial covering
form processing isn't written, yet. :-(

-Jason