Added Python, WSGI to XAMPP

[Ian Kelly]

On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno <greno at 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