Defining the Domain Model

Let's make changes to our stock cookiecutter-generated application. We will define two resource constructors, one representing a wiki page, and another representing the wiki as a mapping of wiki page names to page objects. We will do this inside our models.py file.

Because we are using ZODB to represent our resource tree, each of these resource constructors represents a domain model object. We will call these constructors "model constructors". Both our Page and Wiki constructors will be class objects. A single instance of the "Wiki" class will serve as a container for "Page" objects, which will be instances of the "Page" class.

参考

We will introduce a lot of concepts throughout the remainder of this tutorial. See also the chapter Resources for a complete description of resources and the chapter Traversal for the technical details of how traversal works in Pyramid.

Delete the database

In the next step, we will remove the MyModel Python model class from our models package. Since this class is referred to within our persistent storage (represented on disk as a file named Data.fs), we will have strange things happen the next time we want to visit the application in a browser.

Remove the Data.fs from the tutorial directory before proceeding any further. It is always fine to do this as long as you don't care about the content of the database. The database itself will be recreated as necessary.

Edit models package

注釈

There is nothing special about the package name models. A project may have many models throughout its codebase in arbitrarily named files and directories. Files that implement models often have model in their names, or they may live in a Python subpackage of your application package named models, but this is only by convention.

Open tutorial/models/__init__.py file and edit it to look like the following:

 1from persistent import Persistent
 2from persistent.mapping import PersistentMapping
 3
 4
 5class Wiki(PersistentMapping):
 6    __name__ = None
 7    __parent__ = None
 8
 9class Page(Persistent):
10    def __init__(self, data):
11        self.data = data
12
13def appmaker(zodb_root):
14    if 'app_root' not in zodb_root:
15        app_root = Wiki()
16        frontpage = Page('This is the front page')
17        app_root['FrontPage'] = frontpage
18        frontpage.__name__ = 'FrontPage'
19        frontpage.__parent__ = app_root
20        zodb_root['app_root'] = app_root
21    return zodb_root['app_root']

The emphasized lines indicate changes, described as follows.

Remove the MyModel class from the generated models/__init__.py file. The MyModel class is only a sample and we're not going to use it.

Next we add an import at the top for the persistent.Persistent class. We will use this for a new Page class in a moment.

1from persistent import Persistent
2from persistent.mapping import PersistentMapping

Then we add a Wiki class.

5class Wiki(PersistentMapping):
6    __name__ = None
7    __parent__ = None

We want it to inherit from the persistent.mapping.PersistentMapping class because it provides mapping behavior. It also makes sure that our Wiki page is stored as a "first-class" persistent object in our ZODB database.

Our Wiki class should have two attributes set to None at class scope: __parent__ and __name__. If a model has a __parent__ attribute of None in a traversal-based Pyramid application, it means that it is the root model. The __name__ of the root model is also always None.

Now we add a Page class.

 9class Page(Persistent):
10    def __init__(self, data):
11        self.data = data

This class should inherit from the persistent.Persistent class. We will give it an __init__ method that accepts a single parameter named data. This parameter will contain the reStructuredText body representing the wiki page content.

Note that Page objects don't have an initial __name__ or __parent__ attribute. All objects in a traversal graph must have a __name__ and a __parent__ attribute. We do not specify these here. Instead both __name__ and __parent__ will be set by a view function when a Page is added to our Wiki mapping. We will create this function in the next chapter.

As a last step, edit the appmaker function.

13def appmaker(zodb_root):
14    if 'app_root' not in zodb_root:
15        app_root = Wiki()
16        frontpage = Page('This is the front page')
17        app_root['FrontPage'] = frontpage
18        frontpage.__name__ = 'FrontPage'
19        frontpage.__parent__ = app_root
20        zodb_root['app_root'] = app_root
21    return zodb_root['app_root']

The root resource of our application is a Wiki instance.

We will also slot a single page object (the front page) into the Wiki within the appmaker. This will provide traversal a resource tree to work against when it attempts to resolve URLs to resources.

View the application in a browser

We cannot. At this point, our system is in a "non-runnable" state We will need to change view-related files in the next chapter to be able to start the application successfully. If you try to start the application (See Start the application), you will wind up with a Python traceback on your console that ends with this exception:

ImportError: cannot import name MyModel

This will also happen if you attempt to run the tests.