On 12/16/2010 04:36 AM, Octavian Rasnita wrote: > From: "Ian Kelly" <ian.g.ke...@gmail.com> > > 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. >> > 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 > > >
Javascript is like Ajax only it is client-side. Javascript acts as Controller and does mini-MVC based on bits of 'local' Model and sometimes uses Ajax in the background to perform other mini-MVC transactions back to the server to retrieve data or View parts. All of this, webapp, Ajax, Javascript is doing MVC only at different levels and scopes. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
