Thanks guys! All of the information really helped, I was able to put it to practical use!
On Nov 12, 12:24 am, Mike Orr <[email protected]> wrote: > On Wed, Nov 10, 2010 at 10:19 PM, Andrew <[email protected]> wrote: > > ==What I am trying to do== > > Let me explain a bit more of what I am trying to do. > > Suppose there is a database, exampledb, and I would like to be able to > > pull data out of that database (I am using SQLAlchemy and python > > MySQL), and display that data on a web page. > > > At the moment, I am able to display values I pull from the exampledb > > database on the console (using a simple controller script below) but I > > need some help using it with MVC and displaying on a webpage. > > > == What I Understand == > > - I understand the controller will call on the models or the views and > > return data to the model (please correct if this is wrong). > > - The model is where I can put the database connection (for example, > > like the script below) and query and store the values into variables. > > - Then I would use a MAKO template to display those variables on a > > webpage, but I am not sure of how to assign the variables or define > > the function in the model/controller. > > In Pylons' MVC, the model knows only about the database and your > business objects (e.g., a ``Person`` record). The view (synonymous > with template in Pylons) knows only about the HTML and the > 'tmpl_context' ('c') variables that have been given to it. The > controller knows about both. It queries the model or modifies the > model, sets 'c' variables, and invokes the template. A typical > controller will set ``c.person = some_person_retrieved_from_model`` or > ``c.persons = list_of_persons``. (Some users allow the view to access > the model directly for trivial lookups; e.g., to expand abbreviations > or codes found in the list of persons, if they are stored in a dict in > the model.) > > The goal of MVC is that each of these parts can be replaced or > modified without breaking the application, as long as the interface > between the parts remains constant. So your boss tells you to add some > green help text to a certain place on the page, or to add a mobile > phone field. Or you decide to switch template engines to Genshi. You > only have to make these changes in the view or model, but the 'person' > record as a whole remains the same, so the syntax of the other two > parts doesn't have to change. > > (Of course, in order to use the new field in your views, you'd have to > modify them. And to set this new field, you'd have to modify the "edit > person" actions in the controller. And if you switch template engines, > you'd have to import ``render_genshi`` instead of ``render_mako`` in > your controllers and also make changes in environment.py. But still, > the MVC boundaries mostly confine the changes to one part.) > > But sometimes it can be hard to tell whether an object is truly a > "model-thing", a "view-thing", or a "controller-thing". Pylons has no > good place for view logic: largish chunks of Python code that > calculate presentation-specific data. You can embed Python in Mako > templates or in functions they call, but it's harder to debug > execptions that occur in templates vs in regular Python modules. So > many people end up putting this code in the controller even though > it's arguably "view code". > > MVC has its limitations because it was created for a very different > environment than the web. It was created in the 1980s for low-level > I/O (keystrokes and graphics library = view). There are several > different interpretations of it for the web, all equally valid. Django > calls controllers "views" and the framework the controller. One Java > frameworks envisions the database as separate from the model (the db > is outside MVC). In other interpretations, the view queries the model, > or the controller passes a model to the view (an object equivalent to > all 'c' variables). > > When Pylons and Turbogears were created in 2005, they chose an MVC > interpretation that seemed best for them. Since then, seeing the > difficulties some applications have in determining where all its > objects belong, or in putting view code in the controller, some > Pylons/TG developers have begun to question the rigidness of the > boundaries and whether MVC is well suited to the web. So the next > version of Pylons (Pyramd) will have some changes in Django's > direction. But you needn't worry about that now. All developers agree > that it's important to keep business objects in the model and display > stuff in the view in general, but don't go stressing out in boundary > cases where it's unclear where something goes. > > > == Example of Controller.py == > > from sqlalchemy import * > > > engine = create_engine('mysql://user:p...@localhost/exampledb > > charset=utf8&use_unicode=0') > > connection = engine.connect() > > > result = engine.execute("select field from exampledb") > > for row in result: > > print "name:", row['name'] > > result.close() > > > :::Note:::this only prints it to console > > This is all model stuff. If you answer "y" to SQLAlchemy when creating > a Pylons application, it makes a skeleton model with create_engine() > for you. Normally you would use SQLAlchemy ORM rather than > engine.execute. There is some disagreement whether to put just the > table definitions in the model, or to also make class methods wrapping > the queries. So in different Pylons apps you may see the queries in > the model or in the controller or both, or you may see the query > object go from the model to the controller to the view. This is an > example of how different people interpret MVC differently. > > -- > 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.
