On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno <gr...@verizon.net> wrote: > The VIEW is the bits that stream out of the webserver back to the users > browser. The CONTROLLER is the code that gathers all the pieces from > the model and constructs the python code that is then fed to the engine > that then creates the view. And just because the controller navigates > the logic to dynamically contruct/render a view, that does not make 'it' > the view.
In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. In that light, I think that this quote from the Django FAQ is defensible: > 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. Traditionally, the view would describe both of these things, but since "how you see it" is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. I suppose that "view" tends to prevail since there are other components, such as URL dispatch, that are controllerish in nature. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the "view" as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
