Added Python, WSGI to XAMPP

[Octavian Rasnita]

From: "Ian Kelly" <ian.g.kelly at gmail.com>

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. 

Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way.

> 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.  

How can the view know what data it should render if the controller doesn't inform it about it?
It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller.

And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access 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.

But if the view doesn't decide how the data looks, who decide it? :-)

> 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.

The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site...


> 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.  

The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things.
Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives.

> 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.  

Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed.

> 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

There is no "traditional MVC". There is just MVC or not MVC.
The view shouldn't have any kind of continuity. The view should just present the data. HTTP is a stateless protocol and the controller that handles the requests, does URL dispatching, uses cookies or URL-based ways for maintaining that continuity, not the view.

The so called "non-traditional" MVC idea appeared because many web apps use a lot of Javascript these days, and because of this thing Javascript gained a much bigger importance, and the Javascript programmers would like to happen everything in the view if possible because they don't like to depend so much on the server-side code.

Octavian