From 0aed1cdd37fb57663b978d1d8728d5b652b0b092 Mon Sep 17 00:00:00 2001 From: Carlos de la Guardia Date: Tue, 15 Mar 2011 20:35:02 -0400 Subject: Restructured the routes wiki tutorial to make it easier to follow along. Moved the routes tutorial above the traversal tutorial. --- docs/tutorials/wiki2/definingmodels.rst | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) (limited to 'docs/tutorials/wiki2/definingmodels.rst') 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: -- cgit v1.2.3