5. CREATING A PYRAMID PROJECT
9 directory = myproject/locale
10domain = MyProject
11statistics = true
12
13[extract_messages]
14add_comments = TRANSLATORS:
15output_file = myproject/locale/MyProject.pot
16width = 80
17
18[init_catalog]
19domain = MyProject
20input_file = myproject/locale/MyProject.pot
21output_dir = myproject/locale
22
23[update_catalog]
24domain = MyProject
25input_file = myproject/locale/MyProject.pot
26output_dir = myproject/locale
27previous = true
The values in the default setup file allow various commonly-used internationalization commands and testing commands to work more smoothly.
5.9 The myproject Package
The myproject package lives inside the MyProject project. It contains:
1.An __init__.py file signifies that this is a Python package. It also contains code that helps users run the application, including a main function which is used as a entry point for commands such as pserve, pshell, pviews, and others.
2.A templates directory, which contains Chameleon (or other types of) templates.
3.A tests.py module, which contains unit test code for the application.
4.A views.py module, which contains view code for the application.
These are purely conventions established by the scaffold: Pyramid doesn’t insist that you name things in any particular way. However, it’s generally a good idea to follow Pyramid standards for naming, so that other Pyramid developers can get up to speed quickly on your code when you need help.
54
5.9. THE MYPROJECT PACKAGE
5.9.1 __init__.py
We need a small Python module that configures our application and which advertises an entry point for use by our PasteDeploy .ini file. This is the file named __init__.py. The presence of an __init__.py also informs Python that the directory which contains it is a package.
1 from pyramid.config import Configurator
2
3 def main(global_config, **settings):
4""" This function returns a Pyramid WSGI application.
5"""
6config = Configurator(settings=settings)
7 config.add_static_view(’static’, ’static’, cache_max_age=3600) 8 config.add_route(’home’, ’/’)
9config.scan()
10return config.make_wsgi_app()
1.Line 1 imports the Configurator class from pyramid.config that we use later.
2.Lines 3-10 define a function named main that returns a Pyramid WSGI application. This function is meant to be called by the PasteDeploy framework as a result of running pserve.
Within this function, application configuration is performed. Line 6 creates an instance of a Configurator.
Line 7 registers a static view, which will serve up the files from the myproject:static asset specification (the static directory of the myproject package).
Line 8 adds a route to the configuration. This route is later used by a view in the views module.
Line 9 calls config.scan(), which picks up view registrations declared elsewhere in the package (in this case, in the views.py module).
Line 10 returns a WSGI application to the caller of the function (Pyramid’s pserve).
5.9.2 views.py
Much of the heavy lifting in a Pyramid application is done by view callables. A view callable is the main tool of a Pyramid web application developer; it is a bit of code which accepts a request and which returns a response.
55
5. CREATING A PYRAMID PROJECT
1
2
3
4
5
from pyramid.view import view_config
@view_config(route_name=’home’, renderer=’templates/mytemplate.pt’) def my_view(request):
return {’project’:’MyProject’}
Lines 3-5 define and register a view callable named my_view. The function named my_view is decorated with a view_config decorator (which is processed by the config.scan() line in our __init__.py). The view_config decorator asserts that this view be found when a route named home is matched. In our case, because our __init__.py maps the route named home to the URL pattern /, this route will match when a visitor visits the root URL. The view_config decorator also names a renderer, which in this case is a template that will be used to render the result of the view callable. This particular view declaration points at templates/mytemplate.pt, which is a asset specification that specifies the mytemplate.pt file within the templates directory of the myproject package. The asset specification could have also been specified as myproject:templates/mytemplate.pt; the leading package name and colon is optional. The template file it actually points to is a Chameleon ZPT template file.
This view callable function is handed a single piece of information: the request. The request is an instance of the WebOb Request class representing the browser’s request to our server.
This view returns a dictionary. When this view is invoked, a renderer converts the dictionary returned by the view into HTML, and returns the result as the response. This view is configured to invoke a renderer which uses a Chameleon ZPT template (templates/my_template.pt).
See Writing View Callables Which Use a Renderer for more information about how views, renderers, and templates relate and cooperate.
latex-note.png
Because our development.ini has a pyramid.reload_templates = true directive indicating that templates should be reloaded when they change, you won’t need to restart the application server to see changes you make to templates. During development, this is handy. If this directive had been false (or if the directive did not exist), you would need to restart the application server for each template change. For production applications, you should set your project’s pyramid.reload_templates to false to increase the speed at which templates may be rendered.
56
5.9. THE MYPROJECT PACKAGE
5.9.3 static
This directory contains static assets which support the mytemplate.pt template. It includes CSS and images.
5.9.4 templates/mytemplate.pt
The single Chameleon template that exists in the project. Its contents are too long to show here, but it displays a default page when rendered. It is referenced by the call to @view_config as the renderer of the my_view view callable in the views.py file. See Writing View Callables Which Use a Renderer for more information about renderers.
Templates are accessed and used by view configurations and sometimes by view functions themselves. See Using Templates Directly and Templates Used as Renderers via Configuration.
5.9.5 tests.py
The tests.py module includes unit tests for your application.
1 import unittest
2
3 from pyramid import testing
4
5 class ViewTests(unittest.TestCase):
6def setUp(self):
7self.config = testing.setUp()
8
9def tearDown(self):
10 |
testing.tearDown() |
11 |
|
12def test_my_view(self):
13from .views import my_view
14request = testing.DummyRequest()
15info = my_view(request)
16self.assertEqual(info[’project’], ’MyProject’)
This sample tests.py file has a single unit test defined within it. This test is executed when you run python setup.py test. You may add more tests here as you build your application. You are not required to write tests to use Pyramid, this file is simply provided as convenience and example.
See Unit, Integration, and Functional Testing for more information about writing Pyramid unit tests.
57