Skip to content
Fetching contributors…
Cannot retrieve contributors at this time
136 lines (106 sloc) 5.59 KB

Basic Layout

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` based) projects.

The source code for this tutorial stage can be browsed via

App Startup with

A directory on disk can be turned into a Python :term:`package` by containing an file. Even if empty, this marks a directory as a Python package. Our application uses 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 egg:tutorial#app. In our application, because the application's file says so, this entry point happens to be the app function within the file named

  1. Lines 1-2. Perform some dependency imports.
  2. Line 12. Get the ZODB configuration from the development.ini file's [app:main] section represented by the settings dictionary passed to our app function. This will be a URI (something like file:///path/to/Data.fs).
  3. Line 15. We create a "finder" object using the PersistentApplicationFinder helper class, passing it the ZODB URI and the "appmaker" we've imported from
  4. Lines 16 - 17. We create a :term:`root factory` which uses the finder to return a ZODB root object.
  5. Line 18. We construct a :term:`Configurator` with a :term:`root factory` and the settings keywords parsed by PasteDeploy. The root factory is named get_root.
  6. Lines 19-21. Begin configuration using the begin method of the :meth:`pyramid.configuration.Configurator` class, load the configure.zcml file from our package using the :meth:`pyramid.configuration.Configurator.load_zcml` method, and end configuration using the :meth:`pyramid.configuration.Configurator.end` method.
  7. Line 22. Use the :meth:`pyramid.configuration.Configurator.make_wsgi_app` method to return a :term:`WSGI` application.

Configuration With configure.zcml

The pyramid_zodb template uses :term:`ZCML` to perform system configuration. The ZCML file generated by the template looks like the following:

  1. Line 1. The root <configure> element.

  2. Line 4. Boilerplate, the comment explains.

  3. Lines 6-10. Register a <view> that names a context type that is a class. .views.my_view is a function we write (generated by the pyramid_zodb template) that is given a context object and a request and which returns a dictionary. The renderer tag indicates that the templates/ template should be used to turn the dictionary returned by the view into a response. templates/ is a relative path: it names the file which lives in the templates subdirectory of the directory in which this configure.zcml lives in. In this case, it means it lives in the tutorial package's templates directory as

    Since this <view> doesn't have a name attribute, it is the "default" view for that class.

  4. Lines 12-15. Register a static view 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 path element of this tag is a relative directory name, so it finds the resources it should serve within the static directory inside the tutorial package.

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 file is where the pyramid_zodb Paster template put the classes that implement our model objects.

Here is the source for

  1. Lines 3-4. The MyModel class we referred to in the ZCML file named configure.zcml is 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 __parent__ and __name__ are important parts of the :term:`traversal` protocol. By default, have these as None indicating that this is the :term:`root` object.

  2. Lines 6-12. appmaker is 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.

Something went wrong with that request. Please try again.