Файл: pyramid.pdf

1.1. WHAT MAKES PYRAMID UNIQUE

1.1.27 “Global” response object

“Constructing these response objects in my view callables is such a chore! And I’m way too lazy to register a response adapter, as per the prior section,” you say. Fine. Be that way:

1 def aview(request):

2response = request.response

3response.body = ’Hello world!’

4 response.content_type = ’text/plain’

5return response

See also Varying Attributes of Rendered Responses.

1.1.28 Automating repetitive configuration

Does Pyramid’s configurator allow you to do something, but you’re a little adventurous and just want it a little less verbose? Or you’d like to offer up some handy configuration feature to other Pyramid users without requiring that we change Pyramid? You can extend Pyramid’s Configurator with your own directives. For example, let’s say you find yourself calling pyramid.config.Configurator.add_view() repetitively. Usually you can take the boring away by using existing shortcuts, but let’s say that this is a case such a way that no existing shortcut works to take the boring away:

Pretty tedious right? You can add a directive to the Pyramid configurator to automate some of the tedium away:

17

1. PYRAMID INTRODUCTION

6 view = getattr(module, ’xhr_%s_view’ % method, None)

7if view is not None:

8config.add_view(view, route_name=’xhr_route’, xhr=True,

10

11config = Configurator()

12config.add_directive(’add_protected_xhr_views’, add_protected_xhr_views)

Once that’s done, you can call the directive you’ve just added as a method of the Configurator object:

Your previously repetitive configuration lines have now morphed into one line.

You can share your configuration code with others this way too by packaging it up and calling add_directive() from within a function called when another user uses the include() method against your code.

See also Adding Methods to the Configurator via add_directive.

1.1.29 Testing

Every release of Pyramid has 100% statement coverage via unit and integration tests, as measured by the coverage tool available on PyPI. It also has greater than 95% decision/condition coverage as measured by the instrumental tool available on PyPI. It is automatically tested by the Jenkins tool on Python 2.6, Python 2.7, Python 3.2 and PyPy after each commit to its GitHub repository. Official Pyramid addons are held to a similar testing standard. We still find bugs in Pyramid and its official add-ons, but we’ve noticed we find a lot more of them while working on other projects that don’t have a good testing regime.

Example: http://jenkins.pylonsproject.org/

1.1.30 Support

It’s our goal that no Pyramid question go unanswered. Whether you ask a question on IRC, on the Pylonsdiscuss maillist, or on StackOverflow, you’re likely to get a reasonably prompt response. We don’t tolerate “support trolls” or other people who seem to get their rocks off by berating fellow users in our various offical support channels. We try to keep it well-lit and new-user-friendly.

Example: Visit irc://freenode.net#pyramid (the #pyramid channel on irc.freenode.net in an IRC client) or the pylons-discuss maillist at http://groups.google.com/group/pylons-discuss/ .

18

1.2. WHAT IS THE PYLONS PROJECT?

1.1.31 Documentation

It’s a constant struggle, but we try to maintain a balance between completeness and new-user-friendliness in the official narrative Pyramid documentation (concrete suggestions for improvement are always appreciated, by the way). We also maintain a “cookbook” of recipes, which are usually demonstrations of common integration scenarios, too specific to add to the official narrative docs. In any case, the Pyramid documentation is comprehensive.

Example: The rest of this documentation and the cookbook at http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/ .

1.2 What Is The Pylons Project?

Pyramid is a member of the collection of software published under the Pylons Project. Pylons software is written by a loose-knit community of contributors. The Pylons Project website includes details about how Pyramid relates to the Pylons Project.

1.3 Pyramid and Other Web Frameworks

The first release of Pyramid’s predecessor (named repoze.bfg) was made in July of 2008. At the end of 2010, we changed the name of repoze.bfg to Pyramid. It was merged into the Pylons project as Pyramid in November of that year.

Pyramid was inspired by Zope, Pylons (version 1.0) and Django. As a result, Pyramid borrows several concepts and features from each, combining them into a unique web framework.

Many features of Pyramid trace their origins back to Zope. Like Zope applications, Pyramid applications can be easily extended: if you obey certain constraints, the application you produce can be reused, modified, re-integrated, or extended by third-party developers without forking the original application. The concepts of traversal and declarative security in Pyramid were pioneered first in Zope.

The Pyramid concept of URL dispatch is inspired by the Routes system used by Pylons version 1.0. Like Pylons version 1.0, Pyramid is mostly policy-free. It makes no assertions about which database you should use, and its built-in templating facilities are included only for convenience. In essence, it only supplies a mechanism to map URLs to view code, along with a set of conventions for calling those views. You are free to use third-party components that fit your needs in your applications.

19

1. PYRAMID INTRODUCTION

The concept of view is used by Pyramid mostly as it would be by Django. Pyramid has a documentation culture more like Django’s than like Zope’s.

Like Pylons version 1.0, but unlike Zope, a Pyramid application developer may use completely imperative code to perform common framework configuration tasks such as adding a view or a route. In Zope, ZCML is typically required for similar purposes. In Grok, a Zope-based web framework, decorator objects and class-level declarations are used for this purpose. Out of the box, Pyramid supports imperative and decorator-based configuration; ZCML may be used via an add-on package named pyramid_zcml.

Also unlike Zope and unlike other “full-stack” frameworks such as Django, Pyramid makes no assumptions about which persistence mechanisms you should use to build an application. Zope applications are typically reliant on ZODB; Pyramid allows you to build ZODB applications, but it has no reliance on the ZODB software. Likewise, Django tends to assume that you want to store your application’s data in a relational database. Pyramid makes no such assumption; it allows you to use a relational database but doesn’t encourage or discourage the decision.

Other Python web frameworks advertise themselves as members of a class of web frameworks named model-view-controller frameworks. Insofar as this term has been claimed to represent a class of web frameworks, Pyramid also generally fits into this class.

You Say Pyramid is MVC, But Where’s The Controller?

The Pyramid authors believe that the MVC pattern just doesn’t really fit the web very well. In a Pyramid application, there is a resource tree, which represents the site structure, and views, which tend to present the data stored in the resource tree and a user-defined “domain model”. However, no facility provided by the framework actually necessarily maps to the concept of a “controller” or “model”. So if you had to give it some acronym, I guess you’d say Pyramid is actually an “RV” framework rather than an “MVC” framework. “MVC”, however, is close enough as a general classification moniker for purposes of comparison with other web frameworks.

20