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.
