On Wed, Jun 11, 2008 at 3:14 PM, Ben Bangert <[EMAIL PROTECTED]> wrote: > On Jun 11, 2008, at 1:10 PM, Karlo Lozovina wrote: > >> What's the practical difference between controller based approach and >> views based one? Eg. Django views, and controllers in Pylons? It >> doesn't seem that much different, so why not make all controller >> actions regular functions, instead of class methods? What's the gain >> in this controller approach, if any? :) > > Terminology really. Note that webapps in general are only vaguely mapped to > the entire MVC concept in that you have a model representing domain logic > (generally with a database), a controller that gets the request and decides > how to respond, and a view (template) which the controller uses to create > the response with the data (Model).
As I heard it, the original Smalltalk MVC encapsulated low-level I/O (keystrokes and placing characters on the screen), not "business objects" and "templates" as it's being used for now. So both Pylons and Django and other patterns can be seen as legitimate descendants of it. Most Python frameworks and Python web developers follow the same pattern as Pylons: the model knows nothing about the other two and the view/template doesn't either. The controller knows about both and also about the request input. The controller should put everything the view needs into 'c' variables. Sometimes this gets tedious and developers cheat a little, by allowing the template to look up data directly in the model or in a 'lib' module or imported module. The could be useful for <select> options. Maybe the template wants to pop a one-time 'Flash' message from the session. Or maybe to get the name of a secondary object (e.g., if the current page is a Terrier in the Dogs section. the template might convert parent ID 32 to "Dogs" for a section header or breadcrumb.) But in all these cases it would be only trivial side data, generally read-only, not the request's main read/write objects. The downside is that it makes the view dependent on other parts of the application, creating an intricate set of cross-dependencies which MVC was intended to avoid. I saw a Java MVC that's totally different. The view knows about the model and actively puts things into it and takes things out of it. The controller does not know much about the model (if I remember right). The database is also distinct from the model; the view talks to the database (!). Then there's a separate scratchpad (akin to session variables or 'c' variables). To me this is totally wrong. But then I saw a wxPython application that also has the view using the model, and the speaker recommended this pattern, so it seems to be widespread. The biggest problem in MVC is deciding what's a "model thing" and what's a "view thing". Some people put only their table defintions and trivial ORM classes in their model, and all the query logic in their controllers. Others put high-level data-access functions in the model, and do not allow the controllers to access tables directly. I put class methods in my ORM objects which return queries or calculation results. Controllers never look at the tabes, and use the Session only for writing. Then there's the FormEncode validators. Are these model things or view things? On the one hand they're data-related. On the other hand, the entire HTTP string format is externally imposed by the view and UI; it would not exist if the model were used in a non-webapp such a GUI app. So why should the model know about it? I resolved this dilemma by putting validators in a separate package (myapp.validators). What about a table that's used read-only to display a header or select options? Is that a model thing or a view thing? Depends on its purpose. And perhaps on whether it's defined in the database or a literal dict. What if you have a dozen of these little bobbies? Do you put them all in the model and pass them to the template via 'c' variables? But even though there are border cases like these, MVC is good to keep types of logic generally in its place so that if different people maintain the controllers and templates, they know where to look for what. > So Django is more-or-less MVC, they just call it MTV (Model-Template-View), > and their 'View' is doing the logic with the request, fetching data from the > Model, and using a template (aka, view), to return a response. By any > definition of MVC I've seen, Django is without a doubt MVC as well: > http://en.wikipedia.org/wiki/Model-view-controller > > They've provided a reason for why they choose to call it MTV on their FAQ > page, which differs from every other web frameworks rather unanimous > interpretation of it, and so far has led to more than a little confusion > when I've seen Django users using other MVC frameworks and frequently asking > about 'views' when people understand that to be 'controllers'. Well, this discrepency is unfortunate, and we should probably explain the difference in our documentation for those who've read the Django docs. It's only the word "view" that's ambiguous. "Template" is the same in both dialects, and experienced Django developers will understand what you mean by "controller". It's not unlike the ambiguity of "public school". In the US it means a government-funded school for everybody. In England it means a kind of private school. Some newspapers (can't remember if it's the Times or the Guardian) thus avoid the term entirely and use "state school" and "private school" instead, which are understood by all. This would suggest using "template" more rather than "view", which most Pylons users do anyway except when discussing MVC. As for JJ's "view data", where do you put that in Pylons? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
