The starter files generated by the
pyramid_zodb template are basic,
but they provide a good orientation for the high-level patterns common
to most :term:`traversal` -based :mod:`pyramid` (and :term:`ZODB`
The source code for this tutorial stage can be browsed via http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/basiclayout/.
App Startup with
A directory on disk can be turned into a Python :term:`package` by containing
__init__.py file. Even if empty, this marks a directory as a Python
package. Our application uses
__init__.py as both a package marker, as
well as to contain application configuration code.
When you run the application using the
paster command using the
development.ini generated config file, the application configuration
points at an Setuptools entry point described as
our application, because the application's
setup.py file says so, this
entry point happens to be the
app function within the file named
- Lines 1-2. Perform some dependency imports.
- Line 12. Get the ZODB configuration from the
[app:main]section represented by the
settingsdictionary passed to our
appfunction. This will be a URI (something like
- Line 15. We create a "finder" object using the
PersistentApplicationFinderhelper class, passing it the ZODB URI and the "appmaker" we've imported from
- Lines 16 - 17. We create a :term:`root factory` which uses the finder to return a ZODB root object.
- Line 18. We construct a :term:`Configurator` with a :term:`root
factory` and the settings keywords parsed by PasteDeploy. The root
factory is named
- Lines 19-21. Begin configuration using the
beginmethod of the :meth:`pyramid.configuration.Configurator` class, load the
configure.zcmlfile from our package using the :meth:`pyramid.configuration.Configurator.load_zcml` method, and end configuration using the :meth:`pyramid.configuration.Configurator.end` method.
- Line 22. Use the :meth:`pyramid.configuration.Configurator.make_wsgi_app` method to return a :term:`WSGI` application.
pyramid_zodb template uses :term:`ZCML` to perform system
configuration. The ZCML file generated by the template looks like the
Line 1. The root
Line 4. Boilerplate, the comment explains.
Lines 6-10. Register a
<view>that names a
contexttype that is a class.
.views.my_viewis a function we write (generated by the
pyramid_zodbtemplate) that is given a
contextobject and a
requestand which returns a dictionary. The
renderertag indicates that the
templates/mytemplate.pttemplate should be used to turn the dictionary returned by the view into a response.
templates/mytemplate.ptis a relative path: it names the
mytemplate.ptfile which lives in the
templatessubdirectory of the directory in which this
configure.zcmllives in. In this case, it means it lives in the
<view>doesn't have a
nameattribute, it is the "default" view for that class.
Lines 12-15. Register a
staticview which answers requests which start with
/static. This is a view that will serve up static resources for us, in this case, at
http://localhost:6543/static/and below. The
pathelement of this tag is a relative directory name, so it finds the resources it should serve within the
staticdirectory inside the
Content Models with
:mod:`pyramid` often uses the word :term:`model` when talking about
content resources arranged in the hierarchical object graph
consulted by :term:`traversal`. The
models.py file is where the
pyramid_zodb Paster template put the classes that implement our
Here is the source for
Lines 3-4. The
MyModelclass we referred to in the ZCML file named
configure.zcmlis implemented here. Instances of this class will be capable of being persisted in :term:`ZODB` because the class inherits from the :class:`persistent.mapping.PersistentMapping` class. The
__name__are important parts of the :term:`traversal` protocol. By default, have these as
Noneindicating that this is the :term:`root` object.
appmakeris used to return the application root object. It is called on every request to the :mod:`pyramid` application. It also performs bootstrapping by creating an application root (inside the ZODB root object) if one does not already exist.
We do so by first seeing if the database has the persistent application root. If not, we make an instance, store it, and commit the transaction. We then return the application root object.