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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
:LastChangedDate: $LastChangedDate$
:LastChangedRevision: $LastChangedRevision$
:LastChangedBy: $LastChangedBy$
Web Application Development
===========================
Code layout
-----------
The development of a Twisted Web application should be orthogonal to its
deployment. This means is that if you are developing a web application, it
should be a resource with children, and internal links. Some of the children
might use `Nevow <https://launchpad.net/nevow>`_ , some
might be resources manually using ``.write`` , and so on. Regardless,
the code should be in a Python module, or package, *outside* the web
tree.
You will probably want to test your application as you develop it. There are
many ways to test, including dropping an ``.rpy`` which looks
like:
.. code-block:: python
from mypackage import toplevel
resource = toplevel.Resource(file="foo/bar", color="blue")
into a directory, and then running:
.. code-block:: console
% twistd web --path=/directory
You can also write a Python script like:
.. code-block:: python
#!/usr/bin/env python
from twisted.web import server
from twisted.internet import reactor, endpoints
from mypackage import toplevel
endpoint = endpoints.TCP4ServerEndpoint(reactor, 8080)
endpoint.listen(
server.Site(toplevel.Resource(file="foo/bar", color="blue")))
reactor.run()
Web application deployment
--------------------------
Which one of these development strategies you use is not terribly important,
since (and this is the important part) deployment is *orthogonal* .
Later, when you want users to actually *use* your code, you should worry
about what to do -- or rather, don't. Users may have widely different needs.
Some may want to run your code in a different process, so they'll use
distributed web (:py:mod:`twisted.web.distrib` ). Some may be
using the ``twisted-web`` Debian package, and will drop in:
.. code-block:: console
% cat > /etc/local.d/99addmypackage.py
from mypackage import toplevel
default.putChild(b"mypackage", toplevel.Resource(file="foo/bar", color="blue"))
^D
If you want to be friendly to your users, you can supply many examples in
your package, like the above ``.rpy`` and the Debian-package drop-in.
But the *ultimate* friendliness is to write a useful resource which does
not have deployment assumptions built in.
Understanding resource scripts (``.rpy`` files)
------------------------------------------------
Twisted Web is not PHP -- it has better tools for organizing code Python
modules and packages, so use them. In PHP, the only tool for organizing code is
a web page, which leads to silly things like PHP pages full of functions that
other pages import, and so on. If you were to write your code this way with
Twisted Web, you would do web development using many ``.rpy`` files,
all importing some Python module. This is a *bad idea* -- it mashes
deployment with development, and makes sure your users will be *tied* to
the file-system.
We have ``.rpy`` s because they are useful and necessary.
But using them incorrectly leads to horribly unmaintainable
applications. The best way to ensure you are using them correctly is
to not use them at all, until you are on your *final*
deployment stages. You should then find your ``.rpy`` files
will be less than 10 lines, because you will not *have* more
than 10 lines to write.
|
