Added Python, WSGI to XAMPP

[Gerry Reno]

On 12/15/2010 07:36 PM, Ian Kelly wrote:
> 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
>
>   

Django can use whatever approach they like.  But don't call it an MVC
framework and that is what they did initially at least.  MTV is a
contorted MVC.  And it does not correlate very well with other MVC
documentation which is very confusing to people.

No doubt, the web is constraining.  Request/response makes it difficult
to have the Model independently notify the View that it needs to update
itself because some state in the model has changed.  That is why many of
the diagrams about MVC on the web show the Controller interceding
between the View and the Model.  That doesn't mean MVC does not work on
the web.  It just means that there is a constraint imposed by the nature
of the request/response stateless architecture. 

Maybe it's splitting hairs, but having things named 'View' on the server
implies especially to newbies that the View exists on the server.  The
View exists on the client.  And then later they discover that it's not
really View but Controller and that Templates are View.   I guess if we
were screen-scraping we could actually have a server-side View.  But
normal MVC has the View on the client, and the Model and Controller in
server capacities.  And I don't see the value in naming things View on
the server when for the most part the View (or view parts in the case of
Ajax) are merely the output of render processes.

-Gerry