1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
:mod:`repoze.bfg` Introduction
==============================
:mod:`repoze.bfg` is a Python web application framework based on graph
traversal. It is inspired by Zope's publisher, and uses Zope
libraries to do much of its work. However, it is less ambitious and
less featureful than any released version of Zope's publisher.
:mod:`repoze.bfg` uses the :term:`WSGI` protocol to handle requests
and responses, and integrates :term:`Zope`, :term:`Paste`, and
:term:`WebOb` libraries to form the basis for a simple web object
publishing framework.
Similarities with Other Frameworks
----------------------------------
:mod:`repoze.bfg` was inspired by Zope, Django, and Pylons.
:mod:`repoze.bfg`'s traversal is inspired by Zope. :mod:`repoze.bfg`
uses the Zope Component Architecture ("CA") internally, as do Zope 2,
Zope 3, and Grok. Developers don't interact with the CA very much
during typical development, however; it's mostly used by the framework
developer rather than the application developer.
Like Pylons, :mod:`repoze.bfg` is mostly policy-free. It makes no
assertions about which database you should use, and its built-in
templating facilities are only for convenience. In essence, it only
supplies a mechanism to map URLs to view code, along with a convention
for calling those views. You are free to use third-party components
in your application that fit your needs. Also like Pylons,
:mod:`repoze.bfg` is heavily dependent on WSGI.
The Django docs state that Django is an "MTV" framework in their `FAQ
<http://www.djangoproject.com/documentation/faq/>`_. This also
happens to be true for :mod:`repoze.bfg`::
Django appears to be a MVC framework, but you call the Controller
the "view", and the View the "template". How come you don't use the
standard names?
Well, the standard names are debatable.
In our interpretation of MVC, the "view" describes the data that
gets presented to the user. It's not necessarily how the data looks,
but which data is presented. The view describes which data you see,
not how you see it. It's a subtle distinction.
So, in our case, a "view" is the Python callback function for a
particular URL, because that callback function describes which data
is presented.
Furthermore, it's sensible to separate content from presentation -
which is where templates come in. In Django, a "view" describes
which data is presented, but a view normally delegates to a
template, which describes how the data is presented.
Where does the "controller" fit in, then? In Django's case, it's
probably the framework itself: the machinery that sends a request to
the appropriate view, according to the Django URL configuration.
If you're hungry for acronyms, you might say that Django is a "MTV"
framework - that is, "model", "template", and "view." That breakdown
makes much more sense.
To learn more about the concepts used by :mod:`repoze.bfg`, visit the
:ref:`glossary` for a listing of definitions.
|
