summaryrefslogtreecommitdiff
path: root/docs/tutorials/wiki2/definingmodels.rst
diff options
context:
space:
mode:
authorCarlos de la Guardia <cguardia@hal9001.(none)>2011-03-15 20:35:02 -0400
committerCarlos de la Guardia <cguardia@hal9001.(none)>2011-03-15 20:35:02 -0400
commit0aed1cdd37fb57663b978d1d8728d5b652b0b092 (patch)
tree09057b3bf9ee1a397694e884ff225a599be7f6f1 /docs/tutorials/wiki2/definingmodels.rst
parent9fd15137314f304559479c1846d930a36b0e772e (diff)
downloadpyramid-0aed1cdd37fb57663b978d1d8728d5b652b0b092.tar.gz
pyramid-0aed1cdd37fb57663b978d1d8728d5b652b0b092.tar.bz2
pyramid-0aed1cdd37fb57663b978d1d8728d5b652b0b092.zip
Restructured the routes wiki tutorial to make it easier to follow along. Moved the routes tutorial above the traversal tutorial.
Diffstat (limited to 'docs/tutorials/wiki2/definingmodels.rst')
-rw-r--r--docs/tutorials/wiki2/definingmodels.rst24
1 files changed, 18 insertions, 6 deletions
diff --git a/docs/tutorials/wiki2/definingmodels.rst b/docs/tutorials/wiki2/definingmodels.rst
index 09e1f26c3..117442a1c 100644
--- a/docs/tutorials/wiki2/definingmodels.rst
+++ b/docs/tutorials/wiki2/definingmodels.rst
@@ -31,8 +31,14 @@ application, this class should inherit from an instance of
:class:`sqlalchemy.ext.declarative.declarative_base`. Declarative
SQLAlchemy models are easier to use than directly-mapped ones.
-Our ``Page`` class will have a class level attribute ``__tablename__`` which
-equals the string ``pages``. This means that SQLAlchemy will store our wiki
+.. literalinclude:: src/models/tutorial/models.py
+ :pyobject: Page
+ :linenos:
+ :language: python
+
+As you can see, our ``Page`` class has a class level attribute
+``__tablename__`` which equals the string ``pages``.
+This means that SQLAlchemy will store our wiki
data in a SQL table named ``pages``. Our Page class will also have
class-level attributes named ``id``, ``pagename`` and ``data`` (all instances
of :class:`sqlalchemy.Column`). These will map to columns in the ``pages``
@@ -44,15 +50,21 @@ will hold the body of each page.
We'll also remove our ``populate`` function. We'll inline the
populate step into ``initialize_sql``, changing our ``initialize_sql``
function to add a FrontPage object to our database at startup time.
-We're also going to use slightly different binding syntax. It will
-will otherwise largely be the same as the ``initialize_sql`` in the
+
+.. literalinclude:: src/models/tutorial/models.py
+ :pyobject: initialize_sql
+ :linenos:
+ :language: python
+
+Here, we're using a slightly different binding syntax. It is
+otherwise largely the same as the ``initialize_sql`` in the
paster-generated ``models.py``.
Our DBSession assignment stays the same as the original generated
``models.py``.
-Looking at the Result of Our Edits to ``models.py``
----------------------------------------------------
+Looking at the Result of all Our Edits to ``models.py``
+-------------------------------------------------------
The result of all of our edits to ``models.py`` will end up looking
something like this: